
We're excited to share a significant update about ICY's value model. We've moved from a fixed USDC-backed system to a dynamic Bitcoin-backed model. This change brings new opportunities and considerations for ICY holders. Let's break down what this means for you.

![How much icy worth](assets/how-much-is-your-icy-worth.webp)

## The old model: Simple and stable

Previously, ICY had a straightforward value proposition. Each ICY was worth exactly `1.5 USDC`, and this value remained constant regardless of market conditions. This made it easy to understand and trade, providing stability and predictability for our community.

## The new model: Dynamic and Bitcoin-backed

Now, ICY's value is tied to Bitcoin (BTC) through our liquidity pools. We manage two separate pools, one for ICY and one for BTC, and the interaction between these pools determines ICY's value. The initial conversion rate is set at a predetermined ratio, but the value will fluctuate based on BTC's price and pool dynamics.

### What this means for you

Your ICY's value now depends on three main factors:

- Bitcoin's current market price
- Liquidity pool conditions
- Overall market demand for ICY

Let's look at how these factors work together.

When we add BTC to the pool, it makes ICY more valuable because each ICY is backed by more Bitcoin. Conversely, when we add more ICY to the pool, it reduces the value because each ICY is backed by less Bitcoin.

### Real-world examples

Let's look at how this plays out in practice.
Let's say we start with `1 ICY` being worth `0.00003 BTC`. If Bitcoin is trading at `$50,000`, your ICY would be worth `$1.50`. If Bitcoin's price rises to `$60,000`, your ICY would increase in value to `$1.80`.

Now, let's see how liquidity affects the value. Starting with the same setup (`1 ICY = 0.00003 BTC` at `$50,000`), if we add more BTC to the pool, the ratio might shift to `1 ICY = 0.000035 BTC`, increasing your ICY's value to `$1.75`. On the other hand, if we add more ICY to the pool, the ratio might shift to `1 ICY = 0.000025 BTC`, decreasing your ICY's value to `$1.25`.

### How we manage liquidity

We follow a structured approach to maintain the pools. We add Bitcoin monthly at market prices, and we mint ICY weekly for company activities and rewards. This regular management helps ensure stability while allowing for market-driven value changes.

## Why we made this change

While the USDC model was simple and effective, we believe in evolving with the crypto ecosystem. This new model offers several advantages: it provides growth potential tied to Bitcoin's performance, reduces our dependency on stablecoins, creates a more dynamic and market-driven system, and better reflects real-world trading conditions.

The value of your ICY will now fluctuate based on market conditions. We recommend staying informed about Bitcoin's performance and liquidity pool dynamics to make informed decisions about your ICY holdings.


Learn how ICY's value has evolved from a fixed USDC-backed model to a dynamic Bitcoin-backed system. We'll explain what this means for your holdings and how to track your ICY's value.

How much is your ICY worth


## Objectives

An off-boarding process must ensure three things:

1. Your employee feels good.
2. The departure causes minimal disruption.
3. The termination process must be well-wrapped to make sure the company policy and procedures are all conformed.

## Project offboarding

- [ ] Last day confirmation with client by email
- [ ] Resource replacement
- [ ] Project handoff completed
- [ ] Source code backup

## Company offboarding

### Exit interviews and final communications

- [ ] Exit interview with lead/manager
  - [ ] Gather feedback
  - [ ] Invite to join alumni activities on discords/event
- [ ] Exit talk with HR/Ops
  - [ ] Remind about important points in the Contractor Agreement
- [ ] Last day & final paycheck informed
- [ ] Offboarding email - Remind on survival terms in Contractor Agreement
- [ ] Thank you & farewell letter to personal email
- [ ] Farewell message posted (Optional)
- [ ] Update DF resource planning file
- [ ] Update LinkedIn + endorse Dwarves

### Account and access management

- [ ] Remove email account
- [ ] Remove Git account
- [ ] Remove 1password account
- [ ] Remove Basecamp account
- [ ] Remove access to other work channels
- [ ] Remove database access
- [ ] Update Fortress profile
- [ ] Update Discord Role → Alumni + Remove Discord Access from work-related channels

### Equipment and resources

- [ ] Office card / work device (laptop, phone) if applicable
- [ ] Any other company-owned equipment
- [ ] Remind member to delete source code from their machine

## Post-Departure

- [ ] Follow up on any outstanding items or handover tasks
- [ ] Conduct a brief team meeting to address any gaps left by the departure
- [ ] Update relevant documentation and contact lists

### Handover transfer

- [ ] Conduct handover transfer sessions with team members
- [ ] Document any unique scripts or tools created by the employee
- [ ] Capture information about ongoing experiments or research

Note: This aims for a smooth, positive offboarding that maintains good relations with the departing employee while protecting company interests. The checklist can be adapted to the specific role and company technology/processes.


The process when an employee offboard from the team.

Offboarding


Welcome back to our Devbox series! Previously, we've explored the journey from the early days of virtualization to the widespread adoption of Docker. Finally, we try using Nix and Devbox to enhance software development process. If you need to catch up, you can check out the earlier posts here:

- [Devbox #1: the world before Docker](devbox-a-world-before-docker.md)
- [Devbox #2: our Docker adoption and its challenges](devbox-docker-adoption-and-challenges.md)
- [Devbox #3: the overview into Nix & how we use Devbox @ Dwarves](devbox-nix-and-our-devbox-adoption.md)

Beyond the theories, in this expanded part, we'll show how we use Devbox to create an isolated, reproducible, and portable local development environment.

![](assets/devbox-local-development-env_devbox.gif)

## Engineering = programming + time + people

Programming itself is challenging enough—solving problems by writing code that works. However, engineering extends this challenge: it involves ensuring that code continues to function over time and can be effectively managed and improved by a team of programmers that is changed continuously. This introduces complexities that go beyond initial development. As mentioned in the [What is Software Engineering?](https://research.swtch.com/vgo-eng)

Once the project scales and team grows, the complexity of managing dependencies, tools, and environments also increases. It is an inherent outcome of the collaborative essence of software engineering.

## We can’t control everything manually

Dwarves experienced this complexity firsthand as we welcomed a lot of new talents and projects with varying sizes and tech stacks. Team members are rotated to another project once the current project is done. Because each project has different scales and requirements, each time onboarding happens, team members need to install different tools to begin developing. This situation causes their machine to be filled with a lot of redundant applications and dependencies over time.

Besides, we have no way to track what dependencies are installed or not currently. So we must install them one by one until the project can be executed. You can have your checklist in the _README_. But it just only helps you manually checking it is installed or not, you can’t make sure the installed stuff is compatible with your available applications and you also don’t know the exact version of them. The challenge of managing different tools and dependencies became evident. It forces our members to spend a lot of time setting up new projects under anxiety.

## The road to Devbox

To address this challenge, we adopted several strategies that other successful teams have used. Using containerization tools like Docker can ensure a consistent environment across different projects by packaging applications and their dependencies into isolated containers. Virtual environments and package managers can help manage dependencies specific to each project, reducing conflicts and redundancies. However, Docker images become quite large and unwieldy, making them difficult to manage and distribute efficiently. On the other side, virtual environment and package manager often lack the robustness needed for truly reproducible builds and environments. Finally, we found Nix as a savior.

We took a look at Nix with the expectation of creating a configurable, reproducible, and portable development environment that helps us quickly onboard anybody to any new project with a few simple commands. It also brings an easy way to manage all installed applications in an isolated or semi-isolated environment.

But Nix needs a huge effort to be applied such as separated syntax and mechanisms. It is also too big to serve our purpose. So we need something more simple, and lightweight but can also take advantage of Nix. This is the reason why finally we chose Devbox for a few first experiments. You can read about Devbox [here](devbox-nix-and-our-devbox-adoption.md).

## Devbox simple setup

Our purpose is creating a configurable, isolated, reproducible and portable development environment. So we use Devbox to create an isolated shell in our project root.

```shell
cd way/to/the/project
devbox init
devbox shell --pure
```

In the above commands, when `--pure` is specified, Devbox creates an isolated shell inheriting almost no variables from the current environment. A few variables, in particular `$HOME`, `$USER`, and `$DISPLAY`, are retained.

Once Devbox shell is shown, we can install everything for running our the project including database, git, programming language, code editor, etc. Powered by Nix, Devbox has more than 80,000 packages containing everything you want. You can also specify what is the version that you want when installing it.

```shell
devbox add go@1.21.3
devbox add docker
devbox add docker-compose
devbox add vim
devbox add git
devbox add colima
...
```

After running above commands, the file `devbox.json` in your project root should look like following:

```JSON
{
  "$schema": "<https://raw.githubusercontent.com/jetify-com/devbox/0.10.7/.schema/devbox.schema.json>",
  "packages": [
    "docker@latest",
    "go@1.21.3",
    "docker-compose@latest",
    "git@latest",
    "qemu@latest",
    "vim@latest",
    "vscode@latest",
    "colima@latest"
  ],
  "shell": {
    "init_hook": [
      "echo 'Welcome to devbox!' > /dev/null"
    ],
    "scripts": {
      "test": [
        "echo \\"Error: no test specified\\" && exit 1"
      ]
    }
  }
}
```

You can bring this file to anywhere you want. Once you type `devbox shell`, the exact shell with the same state will be initiated with full installation for all dependencies.

## Bring Devbox to Makefile

To quickly onboarding newbie without any Devbox knowledge, we also trying to turn it to our Makefile as following.

```makefile
shell:
 @if ! command -v devbox >/dev/null 2>&1; then curl -fsSL <https://get.jetpack.io/devbox> | bash; fi
 @devbox install
 @devbox shell

```

With the above simple script, the system firstly checks if Devbox is installed or not. If it is not installed, we try to fetch and install it. Then `devbox install` helps us install all packages mentioned in `devbox.json`. Finally, `devbox shell` starts the shell with ability to inherit your host machine installed things.

Basically, it’s all things that we must do to reach our purpose. But sometimes, edges case still happens. We need some outstanding steps in the first to have a thorough preparation for other people coming later.

## Container runtime configuration

Without container-less purpose, we also need to install container runtime to use `docker-compose` and `docker` in the project. Colima is a nice thing to do it.

There are no problems in the n-time running the Devbox shell. But if it is the first time, we must run the shell with `--pure`. In this situation, we need some small cheats to run Colima.

First is mounting `/usr/bin` to shell `$PATH`, by this way the system can use `sw_vers` to get the environment version. Colima needs this to be started.

```shell
@export PATH=${PATH}:/usr/bin && colima start
```

One more issue comes from Docker config, which is used when running `docker-compose`. We need to cheat by removing `credsStore` in the `~/.docker/config.json`, or installing `osxkeychain` to run Colima normally. You can check [this thread](https://stackoverflow.com/questions/67642620/docker-credential-desktop-not-installed-or-not-available-in-path/72888813#72888813) for more information if you reach this issue.

## Real life usage

You can find a practical example of using Devbox in [our memo repository](https://github.com/dwarvesf/memo.d.foundation). This repository uses Devbox to create an isolated, reproducible, and portable development environment, showcasing how to manage dependencies and streamline development workflows.

## Conclusion

In this installment, we've moved from theory to practice, demonstrating how Devbox creates an isolated, reproducible, and portable development environment. We've shown how to set up Devbox, install dependencies, and integrate it with a Makefile for ease of use. By addressing container runtime challenges, we've ensured a smooth development experience. We hope these insights help streamline your own workflows and enhance your development practices. Thank you for following along, and happy coding!


Expanded section that focuses on Devbox and its practices on setup a local development environment.

Using Devbox to setup local development environment


This is the 3rd post of Devbox series includes

- [Devbox #1: The world before Docker](devbox-a-world-before-docker.md)
- [Devbox #2: Our Docker adoption and its challenges](devbox-docker-adoption-and-challenges.md)
- [Devbox #3: The overview into Nix & how we use Devbox @ Dwarves](devbox-nix-and-our-devbox-adoption.md)

In the previous session, that is [Devbox #2: Our Docker adoption and its challenges](devbox-docker-adoption-and-challenges.md) , we talked about “How Docker is adopted in my development team and its challenges encountered along the way?” And I also talked about a solution to separate us from Docker and containers in setup a local software development environment. And now, It is coming!

As known as a command-line tool, Devbox lets you easily create isolated shells for development. But it doesn't work alone. Because of powering by Nix under the hood, whether you're a newbie or an experienced Nix user, we we need to dissect Devbox beginning by taking about Nix and it power that is superior than Docker.

## Nix is more than a cross-platform package manager

From the [official Nix website](https://nixos.org/), we learn that Nix is a unique cross-platform package management tool that takes a reproducible, declarative and reliable approach to system configuration. However, there's more to Nix than just being a package manager. In fact, the holy trinity of Nix includes Nixpkgs, NixDSL, and NixOS. While they are all called Nix, you can break them down into their respective components for a clearer understanding. With Nix, you use the NixDLS to make Nixpkgs build packages that can be anything from software to entire NixOS images.

Nix builds packages in isolation from each other. This means that if a package works on one machine, it will also work on another. Nix is also declarative and reliable, making it easy to share development and build environments for your projects regardless of the programming languages and tools you're using. Additionally, Nix ensures that installing or upgrading one package doesn't break other packages, allowing you to roll back to previous versions if needed and preventing any inconsistent state during upgrades.

So, what sets Nix apart from Docker?

## Docker build is linear history

In Docker, each line in the Dockerfile is built into a separate Docker layer when it's executed. It's important to understand that even a minor change in any layer will prompt Docker to rebuild all subsequent layers, regardless of whether changes were made to those lower layers.

Let's take a look at the following Dockerfile.

```BASH
FROM ubuntu
# ...
RUN apt-get install -yq gcc
RUN apt-get install -yq vim mc
RUN apt-get install -yq big package
RUN some-expensive-operation
# ...
```

When you modify any line in a Dockerfile, the underlying layers are rebuilt from scratch, regardless of whether those lower layers have changed or not as in the following diagram. Once `RUN apt-get install -yq vim` is modified to `RUN apt-get install -yq vim mc`, the big package is also rebuilt after that.

![Image1](assets/devbox-nix-and-our-devbox-adoption_1.webp)

## Nix build is dependency graph

In contrast to Docker, Nix build works differently. It uses symlinks to achieve atomic deployment of new versions of the system configuration. This makes rollbacks easy to perform and reduces the complexity of managing dependencies. Under the hood, Nix creates a "map" of all the packages and their dependencies, providing a high-level view of the entire system.

![Image2](assets/devbox-nix-and-our-devbox-adoption_2.webp)

Imagine you have a big box full of toys. Inside the box, there are lots of different toys that are connected to each other in different ways. For example, one toy might be connected to another toy by a string. If you want to play with just one toy, you need to find it in the box and take it out. But if you want to play with all the toys at once, you need to open the box and take them all out.

Nix works the same way. It creates a "map" of all the packages on your computer, and how they depend on each other. When you want to use a package, Nix finds it in the map and uses it. If you want to update a package, Nix changes the map to reflect the new version.

The magic of Nix is that it makes sure that everything works together correctly. It's like having a special box that knows how all the toys are connected, so it can help you play with them without getting confused or losing any of them.

## Docker can access internet while building image

As we discussed in the [Devbox #2: Our Docker adoption and its challenges](devbox-docker-adoption-and-challenges.md), Docker builds can access the public internet, so we can't guarantee that the same image will be built every time, as everything on the internet can change in minutes. Additionally, there are no checks to ensure that the files being fetched are actually the ones you intended for your Docker image. Even if we can push the image to a registry and pull it for running identical containers on different computers. In some edge cases when we can’t access to the online repository so need to build another one, we may not be able to build the required image again if some dependencies have changed on the internet.

## Nix ensures external sources are immutable

Take a look at the following diagram, we can see with the same build expression, Nix can result in the same images. In contrast, we can just only build a Docker Image one time and bring this result everywhere if don’t want any change to happen. How can Nix make it happen?

![Image3](assets/devbox-nix-and-our-devbox-adoption_3.webp)

![Image4](assets/devbox-nix-and-our-devbox-adoption_4.webp)

Nix restricts external sources from being changed without being detected. As a result, Nix build always produces functionally the same output each time they are run. This also makes making changes safer, as a change requires a rebuild. The reason for this is that Nix provides the ability to configure the system state using Nix expressions in the Nix language. Essentially, it's an instruction to Nix on how should it build the package and what the final result should look like.

To further illustrate the point that Nix builds produce the same output each time, we can understand that Nix is implemented as a pure function that always returns the same result for the same input parameters. This means that if you run the same Nix expression multiple times, you will always get the same output.

## Nix also can build Docker image better than Docker build

Nix can build Docker images better than Docker build, here's why: Nix takes advantage of a dirty secret deep within Docker - a content-aware store. However, since Docker build isn't designed to utilize this feature. Nix, on the other hand, can create layered images that only upload the changed layers, making updates more efficient.

A layered image puts every dependency into its own image layer so you only upload the parts of your image that have actually changed. For example, making an update to the webp library to fix a trivial bounds checking vulnerability because nobody writes those libraries in memory-safe languages? The only thing that'd need to be uploaded is that single webp library layer.

![Image5](assets/devbox-nix-and-our-devbox-adoption_5.webp)

Additionally, if you have multiple services in the same repository, they'll share Docker layers with each other without any extra configuration. It's not possible to achieve this level of efficiency with Docker without creating multiple common base images, each containing a bunch of tools and unnecessary bloat that some of your services may never use.

## But Nix needs effort, Devbox is more easy

After all, Nix looks superior to Docker. But not everything is perfect. Nix is more complex, If you and your team do not want to destroy everything and start again, migrating to Nix needs a lot of effort. But we have another simple way to apply Nix in the local development environment, that is using Devbox.

Powered by Nix, Devbox is a command-line tool that makes it easy to create isolated shells for development. By defining the list of packages needed for your development environment, Devbox creates a dedicated space for your application to run without anything related to container or VM.

![Image6](assets/devbox-nix-and-our-devbox-adoption_6.webp)

In practice, Devbox works similarly to a package manager like Yarn - except the packages it manages are at the operating system level (something you would normally install with brew or apt-get). With Devbox, you can access over 400,000 package versions from the Nix Package Registry.

Devbox offers an intuitive interface for creating development environments using the Nix Package Manager, without requiring any knowledge of the Nix language. So, how can we incorporate Devbox into our team's workflow?

## Case study: memo.d.foundation

Looking at [memo.d.foundation](https://github.com/dwarvesf/memo.d.foundation), we use Devbox as a tool to create reproducible development environments, making it easy for new team members to get started with minimal effort. By setting up a Devbox shell config with needed dependencies, new joiners can quickly get started without installing anything beyond Devbox. They can then focus on making the application run locally, avoiding the issue of "It works on my machine." Non-tech team members working on content for this repository can also easily run the project without any concerns.

All above ideas are proved by below transparent configuration file.

![Image7](assets/devbox-nix-and-our-devbox-adoption_7.webp)

Jut only need to bring it to anywhere then using `devbox shell` to setup an reproduced development environment without any outstanding steps likes following.

![Image8](assets/devbox-nix-and-our-devbox-adoption_8.webp)

Finally, easy to run our project without installing any other stuffs

![Image9](assets/devbox-nix-and-our-devbox-adoption_9.webp)

## Case study: docker-less development with Devbox services

In addition, we use Devbox to create a containerless development environment by leveraging Devbox services. Under the hood, it takes advantage of Process-Compose, a simple and flexible scheduler and orchestrator written in Nix, to manage non-containerized applications. With Devbox, we can create and manage servers in the shell using a Docker-compose-like approach without any actual Docker containers needed.

When we install a package using Devbox, it creates a file `process-compose.yaml` in the `./.devbox/virtualenv/` directory. This allows Devbox to manage every package installed inside the shell.

For example, when installing PostgreSQL using Devbox add Postgresql, the resulting `process-compose.yaml` file contains instructions for executing the DB, as shown in the following code.

```BASH
version: "0.5"

processes:
  postgresql:
    command: "pg_ctl start -o \"-k $PGHOST\""
    is_daemon: true
    shutdown:
      command: "pg_ctl stop -m fast"
    availability:
      restart: "always"%

```

If you familiar with docker-compose, I think it is easy to understand process-compose as well. By standing all `process-compose.yaml` both from the root of project and in the `.devbox/`, you can manage how many services are ready to serve by using `devbox services ls`. Then when you enter `devbox services up`, all services in this project will be instructed to run. The special point here is that you can custom the `process-compose.yaml` at the root of project to get the same result as docker-compose without using container.

You also can run different Devbox shells parallel, but can’t run different services from different shells using the same port because we have no separate network here. Take a look at the following example when I try running 2 Postgresql services in different shells with the same port.

![Image10](assets/devbox-nix-and-our-devbox-adoption_10.webp)

So depending on what applications you are running, you will have the proper way to config different ports. For example, can change add one more argument to change the default port of Postgresql in the `process-compose.yaml` to get parallel processes.

```BASH
version: "0.5"

processes:
  postgresql:
    command: "pg_ctl start -o \"-k $PGHOST -p 5433\""
    is_daemon: true
    shutdown:
      command: "pg_ctl stop -m fast"
    availability:
      restart: "always"

```

![Image11](assets/devbox-nix-and-our-devbox-adoption_11.webp)

For now, this is the list of usecases I can provide. As I continue to learn and adapt, I will introduce more in the future.

## Conclusion

In summary, Nix and Devbox offer exciting new possibilities for streamlining software development processes. By providing a more efficient way to create reproducible development environments, Nix and Devbox can help teams overcome challenges and improve overall workflow. While they may not completely replace Docker, they can effectively address different problems and provide additional support where Docker may be struggling.


The overview into Nix & how we use Devbox @ Dwarves


This is the 2nd post of Devbox series includes

- [Devbox #1: The world before Docker](devbox-a-world-before-docker.md)
- [Devbox #2: Our docker adoption and its challenges](devbox-docker-adoption-and-challenges.md)
- [Devbox #3: The overview into Nix & how we use Devbox @ Dwarves](devbox-nix-and-our-devbox-adoption.md)

In the previous session that is [Devbox #1: The world before Docker](devbox-a-world-before-docker.md), we discussed the world from the beginning before container and Docker concepts emerged as groundbreaking advancements in software development. But nothing is perfect! Container and Docker also have their own concerns. So in this session, we will dive deep into Docker in practice with the real-life adoption of my team. Then, we can discover the challenges of containers and Docker and find the right way to go to get more performance.

From the beginning, the desire to produce an isolated environment is raised to provide ability for multiple users accessing a computer concurrently with full resource utilization via a singular application. Over time, various other purposes have been explored and implemented. With the introduction of Docker, container technology became extensively utilized in software development. Two of the most popular uses are creating reproducible development environments and enabling continuous deployment.

## Container deployment era

Compare to other traditional solutions for creating isolated environments, Docker container offers a lot of superior advantages. It requires a significantly smaller resource footprint with the ability to spin up and down faster by using the same OS kernel instead of encapsulating independent OS. This approach allows for leveraging numerous benefits of containerization in the software deployment process.

![](assets/devbox-docker-adoption-and-challenges_01.webp)

Currently, creating and deploying entire applications becomes simple through the use of Docker. With the available immutability characteristics of the Docker image, we can also decouple applications from infrastructure by generating application container images at release time rather than at deployment time.

Furthermore, owing to the preeminence of Docker containers, a lot of services supporting them have experienced robust growth. With millions of pre-packaged applications available on DockerHub, initiating a project becomes swift with just a few commands. Numerous public and private cloud providers offer managed container services, enabling immediate deployment of our applications online. Moreover, an extensive ecosystem has emerged around containers and Docker, providing support for monitoring, security, networking, storage, and integration, letting us have the ability to create a smooth process from development, integration to deployment and testing.

## Docker in development

Sounds massive! But I know some of us will never touch on the entire benefits of Docker containers except if we are a DevOps professional. So, to be more developer-friendly, why don't we take a closer look at the development environment aspect?

When beginning my software development career, I had the opportunity to work in a team with almost all previous-generation developers. In this environment, durability and certainty are prioritized above all else, so everyone is fine with installing a bunch of stuff on their computers to get the project off the ground. I actually needed over 3 days to get the project running, despite having quite detailed documents. After that, I knew others also needed more time. It is acceptable when this is the onboarding phase. The nightmare actually begins when your laptop encounters issues and the deadline is looming. Regardless of how familiar you are with the project, you still need at least 1 day to reinstall everything the risk of not remembering the dependency version. But that's not even the end of it. After I left the project, my laptop became polluted, and I actually didn’t know how to deal with it except by reinstalling my OS.

In another Golang project, a similar situation occurred. When we attempted to install all dependencies locally for development, one of us unwittingly upgraded the version of the Protobuf generator. Consequently, when the code is committed, thousands of changes are generated, even if only one line of code was updated. After this issue arose, we adopted Docker as a lifesaver.

Docker provides an easy way to define and start a local development environment with just a few instructions using a Dockerfile. Through this transparent approach, you can precisely control any library, version, and related resources required to run your application and lock down configurations as needed. So, once you identify the specific library update that caused issues, resolving it becomes straightforward.

![](assets/devbox-docker-adoption-and-challenges_02.webp)

Utilizing Docker simplifies the creation of a reproducible development environment. By initializing dependencies as containers and connecting our application to them, we ensure consistency. However, in this way, the code is actually running in the local environment. For maximum container isolation, we can encapsulate our application in its own container and integrate it with others. Sharing the development environment then becomes as simple as sharing Docker configuration and scripts, enabling seamless collaboration among team members, regardless of location.

It is not just for the backend side; on the frontend, containerization is also widely applied. Docker can be used to create containers that contain the frontend code, dependencies, and any related configurations to run the application, such as images for building specific APIs integrated with this website for use in local development with proper datasets.

However, nothing is perfect, Docker container has its own concerns.

## Nothing is perfect

Yeah, Docker is really fast. It only takes anywhere from a few milliseconds to a few seconds to start a Docker container from a Docker image. But how do you feel when every time you change the code, you have to rebuild the Docker image and restart the container again for debugging? That would be a real nightmare. To avoid it, you can only run the application locally with Docker container dependencies, or rack your brain to find a way to optimize the Dockerfile. Most of the time, it's fine, but the real problem occurs in edge cases.

The same issue arises when our team tries to pack all related development tools into a Docker image. While it successfully avoids the problem of different versions of dependencies, this approach encounters a bottleneck as the time to start the application is longer than usual.

So what is actually happening? In the Docker, each modification to the codebase necessitates rebuilding the image and restarting the container. Despite leveraging build caching, this process can be time-consuming if not managed carefully. It's crucial to recognize that even a minor change in any layer prompts Docker to rebuild all subsequent layers, irrespective of whether alterations were made to those lower layers.

![](assets/devbox-docker-adoption-and-challenges_03.webp)

Furthermore, incorporating packages into a Docker image without proper consideration can lead to inefficiencies. Executing `apt-get upgrade` at the onset of your Docker build might replace files within the container image. Consequently, these surplus files generate redundant shadow copies, gradually consuming additional storage space over time.

One significant issue that is often overlooked is that Docker builds have access to the public internet. If dependencies are pulled directly from the internet during builds, it can make it difficult to ensure reproducibility of builds over time. Different versions of dependencies may be pulled, leading to inconsistencies between builds.

For example, we often include something like `RUN apt-get install ...` in the Dockerfile. This command handles everything necessary for your container to successfully execute your application. However, as mentioned above, this approach doesn't ensure complete reproducibility of the Docker image over time. Each time this command is run, the version of dependencies installed may vary. To mitigate this, we can specify the version of dependencies. However, if that exact version is no longer available, Docker will throw an error.

## What’s new gate?

So, with all the challenges mentioned above, do we have any way to avoid them in a peaceful manner? Certainly, there are various ways to address these problems, but none of them are perfect or bad.

Most of them involve optimizing your approach to using Docker. However, I would like to introduce another approach that keeps us away from Docker during development but still allows us to leverage Docker for deployment. We'll explore that next time in the [Devbox #3: The overview into Nix & how we use Devbox @ Dwarves](devbox-nix-and-our-devbox-adoption.md).


Our second Devbox session, where we discussed our Docker adoption and challenges.

Our docker adoption and its challenges


This is the 1st post of Devbox series includes

- [Devbox #1: The world before Docker](devbox-a-world-before-docker.md)
- [Devbox #2: Our Docker adoption and its challenges](devbox-docker-adoption-and-challenges.md)
- [Devbox #3: The overview into Nix & how we use Devbox @ Dwarves](devbox-nix-and-our-devbox-adoption.md)

## The it-works-on-my-machine time

Sometimes, in my software development team, a strange issue is raised. Nobody can evaluate the issue because 'It works on their machine’.One of Docker's most powerful abilities is cross-platform compatibility, which enables seamless deployment across Linux, Windows, and macOS environments. In this way, it broadens adoption and facilitates interoperability in heterogeneous computing environments.

![](assets/devbox-a-world-before-docker_untitled.webp)

Positively, It is fine because the software actually works somewhere. So you can scope the area of issue and try troubleshooting. But, it is also a red alert on our development process.

I believe it's not just my problem. Throughout the ongoing evolution of software development, others have likely encountered similar problem. This leads me to wonder, 'Have they implemented strategies to address these issues over time?'

Right, as software technology develops, we always have ways to improve the output. It encompasses more than just a solution, it represents a rich evolutionary history within the realm of software development.

## First bullet: Virtual machine

During the 1960s, researchers at IBM's Cambridge Scientific Center delved into the development of the first virtual machine operating system. They aimed to address the burgeoning demand for time-sharing capabilities within the computing industry of that era. Despite initial setbacks encountered with the System/360 series, which lacked adequate time-sharing functionalities, persistent efforts eventually led to the creation of CP/CMS as the first virtual machine.

As VM evolved and became more widely known, its benefits for software development processes would have become apparent. Developers and engineers outside of IBM, upon learning about CP/CMS and its virtual machine capabilities, began to explore how similar concepts could be applied to their development workflows.

By the late 1990s, products like VMware Workstation emerged, enabling the running of multiple virtual machines on a single PC. This facilitated software testing across diverse environments.

Not only just for development testing, VM has been widely adopted for creating reproducible development environments that can be shared among team members by taking advantage of its characteristics such as **reproducibility, isolation, portability, and snapshotting.**

However, challenges arise when it comes to sharing the environment among team members. These bottlenecks include ensuring consistent setups, managing resource constraints, handling dependencies, and coordinating collaboration due to the complexity and resource requirements of VMs. Additionally, VM configurations may depend on the underlying hypervisor and guest operating system.

## Containerization, a breath of fresh air

![](assets/devbox-a-world-before-docker_untitled-2.webp)

While everyone is struggling with VM, the modern containerization movement of the early 2010s was kickstarted by Linux Containers, followed by Docker's public unveiling at PyCon in Santa Clara in 2013, with its subsequent open-source release in March of that year. Since then, there has been a significant transformation in the software development process.

Have a lot of things to discuss, but we can distill the variances between VMs and Containers into the following summary

|                   | Container                                                         | Virtual Machine                                     | Conclusion    |
| ----------------- | ----------------------------------------------------------------- | --------------------------------------------------- | ------------- |
| Isolation         | Share host kernel, lightweight                                    | Run full OS, heavier                                | VM is heavier |
| Resource Overhead | Minimal, efficient use of resources                               | Higher, each VM requires its own OS                 | VM is heavier |
| Startup Time      | Almost instant                                                    | Slower due to booting entire OS                     | VM is heavier |
| Security          | Good isolation, but potential risks if host kernel is compromised | Strong isolation between VMs, larger attack surface | VM is heavier |
| Deployment        | Highly portable                                                   | Flexible but heavier                                | VM is heavier |

## The opening act with Linux containers

As I mentioned above, Linux Containers (LXC) was perhaps the first implementation of a complete container manager. It provide a lightweight and efficient approach to deploying and isolating applications

Unlike VM, which require the overhead of running multiple operating system instances, Linux containers share the host operating system's kernel while maintaining separate namespaces for processes, networking, and file systems. This results in faster startup times, lower resource consumption, and greater scalability compared to VMs.

However, one disadvantage of using Linux Containers directly is the potential lack of comprehensive tooling and ecosystem support, which can lead to integration challenges and a less streamlined development and deployment experience.

In that situation, Docker was born with more innovations.

## Docker - innovation of innovation

One of Docker's most powerful abilities is cross-platform compatibility, which enables seamless deployment across Linux, Windows, and macOS environments. In this way, it broadens adoption and facilitates interoperability in heterogeneous computing environments.

Moreover, Docker has a variety system of extensive tooling, and ecosystem that make a big improvement in container management. such as Docker CLI and Docker Hub. These resources streamline every facet of container deployment, from image creation to orchestration, significantly simplifying the development workflow.

Docker's robust ecosystem also garners widespread support from major cloud providers, ensuring effortless integration and scalability in cloud environments. Its user-friendly interface and intuitive workflow further contribute to its appeal, empowering developers to expedite deployment processes without compromising efficiency or reliability.

Consequently, Docker emerges as the quintessential choice for modern containerization needs, offering unparalleled flexibility, convenience, and efficiency to developers and organizations worldwide.

## Final thoughts

In summary, the transition from traditional Virtual Machines (VMs) to containerization, epitomized by Docker, represents a pivotal advancement in software development. Docker's lightweight, portable containers have revolutionized software development and deployment. However, this transformation is not merely about adopting a new technology; it's a journey marked by adaptation and discovery. In the [Devbox #2: Our Docker adoption and its challenges](devbox-docker-adoption-and-challenges.md), we will uncover the story: how Docker is adopted in my development team and its challenges encountered along the way.


A brief history about the world before Docker and why we need devbox for local development

The world before Docker


We know there are countless Discord servers out there. Ours aims to be different. From the start, we designed it as a space _for developers_, prioritizing genuine connection and knowledge sharing over corporate speak. We operate it as a blend of company and community because we believe that's the most valuable approach.

So, what actually happens here?

- **We share knowledge:** We discuss software insights through seminars, casual channel chats, and tech talks. If it's about development, it's welcome.
- **We connect with people:** This is our virtual space to hang out with friends, alumni, and like-minded developers. No forced networking.
- **We build in the open:** We're creating a software network people genuinely want to join. Discord is central to that effort.

We recently reorganized the channels to hopefully make navigation and connection easier. Here's a breakdown:

## Where stuff happens: the channels

Channels fall into two main categories: common areas for everyone and spaces more focused on our internal consulting work.

### Community hangouts (everyone welcome)

- **off-topic:** For general, non-work conversations.
  - `⛺・random`: The place for memes, weekend stories, pet pictures, and anything else off-topic.
  - `📈・trading-cafe`: Discussions about markets, crypto, and trading.
- **research:** The hub for technical discussions.
  - `🌟・starboard`: Notable messages highlighted by the community land here.
  - `💡・til`: Share your "today I learned" moments, big or small.
  - `💻・tech`: General technology discussions, news, and questions.
  - `🎒・topics`: Focused discussions on specific technical subjects.

### Internal & ops channels (mostly for staff & mods)

- **project:** Discussions related to active client projects (primarily for our consulting team).
- **consulting:** The main area for internal team communication.
  - `🏢・lobby`: General company-wide announcements and discussions.
  - `🦄・pink-alert`: For urgent matters needing immediate attention.
- **moderation:** Keeping the community running smoothly.
  - `🗣・community`: Coordination for community initiatives.
  - `🎗️・operation`: Server management and administrative tasks.
- **misc & log:** Essential background channels.
  - `🤖・bot-commands`: Interacting with server bots.
  - `🧊・icy-log`: Automated server activity logs.

## Who's who: Discord roles

We needed a role system that reflects contribution and expertise as we grow, not just arbitrary labels. Our system combines ladder-based roles (earned through participation) and function-based roles (based on responsibilities).

Why this structure? We want to recognize engagement and skill, eventually linking roles to tangible benefits like NFTs and `$icy` staking (more details soon). It's about creating a system that rewards active participation.

![Dwarves network discord Role Structure](assets/discord-role-structure.webp)

### The core MMA roles (mastery, meaning, autonomy)

This system recognizes different types of impact:

- **@labs (mastery):** Your technical skill is recognized and valued by the community.
- **@sers (meaning):** You make meaningful contributions, through quality work or positive community involvement.
- **@chad (autonomy):** You consistently deliver high-quality work effectively and reliably.

### Keeping the lights on (moderation)

- **supporter:** Welcomes new members and helps with daily questions.
- **moderator:** Organizes events, facilitates discussions, and may host talks.
- **smod:** Oversees major community and operational functions.

### Community crew

- **guest:** The starting role for everyone.
- **newbie:** Granted after basic introductions. Welcome aboard!
- **frens:** Actively participates in public channels.
- **contributor:** Helps bring new, valuable members into the community.
- **trustee:** A recognized and trusted voice within the community.

### Consulting staff (our internal team structure)

- **apprentice:** Team members new to Dwarves.
- **baby dwarf:** Developing their focus within the team.
- **dwarf:** Actively participates in R&D and learning.
- **crafter:** Consistently delivers quality software.
- **specialist:** Possesses deep expertise in a specific domain.
- **principle:** Helps maintain and elevate the team's standards.
- **elite:** Guides the team's technical direction.

### Functional roles (what people focus on)

These roles represent key operational areas:

- **engagement:** Aligns the team around vision and values.
- **learning:** Promotes continuous skill development.
- **partnership:** Focuses on client relationships and project acquisition.
- **communication:** Ensures transparent information flow.
- **delivery:** Oversees the quality and shipment of work.

## Our helpful bots

Being developers, we've built bots to automate tasks and add useful features:

- **Mochi:** A tipping bot using `$MOCHI`. Use `!tip` to give a virtual high-five for helpful answers or contributions.
- **Tono:** Our primary server management bot, handling roles and background tasks.
- **Fortress:** An internal tool for tracking performance and issues (less community-facing).

## How do I level up? (the `$icy` system)

We use our custom token, [`$icy`](icy.md), as the server's primary internal currency – think of it as community points.

You earn `$icy` through activity and contributions. Higher engagement leads to more `$icy`, which helps you climb the role ladder.

Achieving certain roles will also eventually grant a boosting NFT, providing tangible value back to our most active members.

That covers the basics! Feel free to jump into a channel and introduce yourself.

See you [on the server!](http://discord.gg/dfoundation)

---

> Next: [Earn](earn.md)


Our Discord isn't just another company server; it's a place for both our team and the wider developer community. This guide explains how it works and where you fit in.

Discord

Dwarves network discord


The Dwarves bounty program is the means through which both company peeps and the community can contribute to our daily activities. This includes tasks like building internal tools, engaging in new technology research and development, or sharing knowledge session.

This program is part of our ICY initiative, which you can learn more about at [handbook](). ICY connects contributors with meaningful projects while rewarding valuable work across our ecosystem.

**→ To contribute**: open ticket in [our Discord](https://discord.gg/dfoundation) and give our mods a ping

No results or invalid data format.

## Naming convention

Our bounty files follow a specific naming pattern to help organize and categorize different types of opportunities:

### File naming format

Files should be named using the pattern: `XXX-descriptive-name.md` where:

- `XXX` is a 3-digit code indicating the bounty category
- `descriptive-name` is a kebab-case description of the bounty

### Category codes

- `0XX` - Continuous research topics with long-term value (e.g., `000-productivity.md`, `001-quality.md`)
- `1XX` - Internal tooling bounties (e.g., `101-discord-bot.md`, `150-memo-search.md`)
- `5XX` - Project-related bounties (e.g., `501-client-project-contribution.md`, `520-code-review.md`)
- `8XX` - Other miscellaneous bounties (e.g., `801-community-event.md`, `850-documentation.md`)

This naming system helps contributors quickly identify the type of bounty and its general purpose within our ecosystem.


The Dwarves bounty program is the means through which both company peeps and the community can contribute to our daily activities. This includes tasks like building internal tools, engaging in new technology research and development, or sharing knowledge session

👾 Open bounties


We're launching the first feature from our 2024 roadmap: an \$icy salary advance.

**tl;dr** It's a short-term credit benefit available to all full-time employees in our company.

![](assets/salary-advance.webp)

e.g:

- hnh earn $5000 a month
- hnh can ask for upto `25%` ($1250) of his monthly allowance in advanced
- the credit will be paid automatically by hnh next pay day, plus `0.5% service fee`

## How to use?

- head over to the DMs of the 'Fortress' bot
- type `?salary advance`
- input credit amount in icy.
- done.


A short-term credit benefit for full-time peeps.

Icy salary advance


**Industry**\
Startup Community / Knowledge Sharing

**Location**\
Vietnam

**Business context**\
Vietnamese entrepreneurs needed a central platform to connect, share experiences, and find resources for their businesses

**Solution**\
Created a comprehensive online community that brings together founders, investors, and ecosystem builders in one place

**Outcome**\
Built a thriving platform that attracted thousands of entrepreneurs and facilitated valuable connections between users

**Our service**\
Full-stack Development / Community Platform / Search Integration

## Technical highlights

- **Backend**: Node.js with Express for scalable, flexible API development
- **Frontend**: React.js with Next.js for fast, responsive user experience
- **Database**: MongoDB for flexible content storage
- **Search**: Elasticsearch for powerful content discovery
- **Architecture**: Microservices design for independent component updates
- **Mobile optimization**: Responsive design for smartphone-first users
- **Security**: Robust authentication and permission systems

## What we did with StartupVN

StartupVN is a community platform designed to bring together Vietnamese entrepreneurs, investors, and ecosystem builders. In a rapidly growing startup scene, founders needed a central place to connect with each other, share experiences, and find resources to help their businesses succeed.

We collaborated with StartupVN to build this online community from the ground up. Our goal was to create a user-friendly platform that would make it easy for entrepreneurs to network, access mentorship, and discover funding opportunities - all in one place.

![StartupVN community platform](assets/startupvn-main.webp)

The platform offers several key features:

- A community forum where founders can ask questions and share insights
- Events listings for networking and learning opportunities
- Resource libraries with guides and tools for startups
- Profiles for startups and founders to showcase their work
- Mentorship connections to link experienced business leaders with new entrepreneurs

## The challenge StartupVN was facing

Vietnam's startup ecosystem has seen incredible growth in recent years, but entrepreneurs faced several challenges:

1. **Scattered information**: Valuable resources, events, and opportunities were spread across many different websites and platforms, making them hard to find
2. **Limited networking**: Many founders, especially those outside major cities, had few chances to connect with other entrepreneurs and investors
3. **Knowledge gaps**: New founders often lacked access to the practical knowledge and mentorship needed to grow their businesses

StartupVN wanted to address these problems with a single, easy-to-use platform. They needed a technical partner who could not only build the solution but also understand the unique needs of the Vietnamese startup community.

## How we built it

We approached this project with a focus on creating a platform that would be both powerful and simple to use. The system needed to handle community discussions, user profiles, event management, and resource libraries while remaining fast and responsive.

### Technical approach

Our technical approach included:

- **Modern API development**: We used Node.js with Express to create a flexible and scalable API that could handle various types of content and user interactions.
- **Fast frontend experience**: We built the user interface with React.js and Next.js to provide a smooth, responsive experience that works well even on slower internet connections.
- **Flexible data storage**: MongoDB offered the flexibility we needed to store diverse content types, from forum posts to event listings to user profiles.
- **Powerful search capabilities**: We implemented Elasticsearch to help users quickly find relevant information across the entire platform.
- **Scalable infrastructure**: We deployed on Google Cloud Platform to ensure reliable performance that could grow as the user base expanded.
- **Microservices architecture**: We built the community features using microservices, allowing different parts of the platform to be updated independently without disrupting the entire system.
- **Realtime engagement**: We implemented notifications to keep users informed about community activities and relevant opportunities.
- **Smart recommendations**: We created a system that connects users with content and opportunities most relevant to their interests and needs.

### Security and accessibility

Security was essential for this platform, so we implemented robust user authentication, permission systems, and data protection measures. We also made sure the platform worked well on mobile devices, as many Vietnamese entrepreneurs primarily use smartphones to access online resources.

### Collaborative development

Throughout development, we worked closely with the StartupVN team, gathering feedback from actual entrepreneurs to refine the platform's features and user experience. This collaborative approach ensured we were building something that truly met the needs of the Vietnamese startup community.

## What we achieved

The StartupVN platform launched successfully and quickly became a valuable resource for Vietnamese entrepreneurs:

- **Growing community**: Thousands of entrepreneurs joined the platform in the first few months
- **Active engagement**: Users regularly participate in discussions, sharing knowledge and supporting each other
- **Resource access**: The platform has made valuable startup resources more accessible, especially for founders outside major cities
- **Successful connections**: Several startups reported finding mentors, partners, and even investors through the platform

StartupVN has continued to evolve, with new features being added based on community feedback. The platform has become an important part of Vietnam's growing startup ecosystem, helping founders connect, learn, and build successful businesses.

> "The platform has transformed how we support entrepreneurs in Vietnam. What used to require multiple disconnected tools and endless email chains now happens seamlessly in one place. This has allowed us to focus on building meaningful relationships within the community rather than managing logistics." , Tuan Anh, Founder of StartupVN

This project demonstrates how thoughtfully designed digital platforms can strengthen entrepreneurial communities and help drive economic growth. By creating a central hub for Vietnam's startup ecosystem, we've helped make entrepreneurial resources and connections more accessible to founders throughout the country.


We helped create a digital hub where Vietnamese startup founders can connect, share knowledge, and access resources to grow their businesses.

StartupVN

Building a community platform for Vietnamese entrepreneurs


**Industry**\
Financial Technology (Fintech)

**Location**\
Singapore

**Business context**\
Payment startup needed to build a secure, scalable platform from scratch

**Solution**\
Developed a multi-tenant cloud platform that connects merchants with payment providers

**Outcome**\
Successfully launched the platform within one year, enabling expansion in Southeast Asia

**Our service**\
Backend development / Cloud architecture / DevOps

## Technical highlights

- **Backend**: TypeScript, Kotlin for reliable microservices
- **Frontend**: React, TypeScript for the merchant interface
- **Infrastructure**: AWS Lambda, EC2, S3, DynamoDB
- **Architecture**: Multi-tenant system with microservices
- **Security**: PCI DSS compliance, encryption for sensitive data
- **DevOps**: Docker, automated CI/CD pipeline

## What we did with Open Fabric

[Open Fabric](https://openfabric.co/) is a "Buy Now, Pay Later" payment platform started by experts from companies like PayPal and Grab. They wanted to create a network that makes it simple for stores to accept digital payments across Southeast Asia.

We put together a team of 8 engineers to help build the technical foundation and create a working product from scratch. We worked closely with their team to develop a system that could connect stores with different payment methods.

Our team was responsible for building the core data system – the foundation of the entire platform. This crucial part allows Open Fabric to handle transactions between customers, stores, and payment providers.

The product we delivered helped Open Fabric launch on time and start growing in Southeast Asia's competitive payment market.

![Open Fabric payment platform dashboard showing transaction analytics](assets/openfabric-main.webp)

## The challenge Open Fabric faced

Open Fabric needed to build a platform that could serve multiple audiences at once:

- **Merchants** who want to offer more payment options to their customers
- **Shoppers** who need secure, convenient payment methods
- **Payment providers** who want to connect with more businesses

These requirements created several complex technical challenges:

- **Processing high transaction volumes**: The system needed to handle many simultaneous payments while maintaining performance.
- **Ensuring data security**: Financial information required strong protection through encryption and secure storage.
- **Meeting industry regulations**: Payment platforms must follow strict compliance standards like PCI DSS.
- **Building for scale**: The architecture needed to support growth as more merchants and payment providers joined the platform.
- **Recruiting specialized talent**: Fintech development requires specific expertise that's difficult to find on short notice.

![Open Fabric business challenges diagram showing market complexity](assets/openfabric-challenges.webp)

## How we built it

We approached the Open Fabric platform with three key priorities: scalability, security, and speed to market – all critical factors for a payment startup in a competitive landscape.

### Technical approach

**Multi-tenant architecture**: We designed the system so a single platform could securely serve many different businesses. This approach:

- Allows both merchants and payment providers to use the same underlying infrastructure
- Maintains strict data separation between tenants for security
- Reduces operational costs compared to deploying separate instances
- Optimizes resource utilization
- Enables easier scaling as the business grows

**Microservices organization**: Even at this early stage, we structured the system into discrete services to improve maintainability and future development:

1. **Data service**: The central system that manages core information used by other components
2. **Transaction service**: Handles payment processing between customers and merchants
3. **Logging service**: Maintains comprehensive audit trails across the platform
4. **Card service**: A highly isolated service that handles sensitive payment card information

![Open Fabric system architecture diagram showing service relationships](assets/openfabric-architecture.webp)

**Cloud-native implementation**: We built the entire platform on Amazon Web Services (AWS):

- **Serverless computing**: Most services run on AWS Lambda, which automatically scales based on demand
- **Containerization**: Docker containers provide isolation between different system components
- **Content delivery**: AWS S3 and CloudFront host static assets like dashboards and documentation
- **Regional optimization**: We deployed in Singapore to minimize latency for Southeast Asian users

![Open Fabric cloud infrastructure diagram showing AWS components](assets/openfabric-cloud.webp)

**Development environment separation**: We created four distinct environments to support the development lifecycle:

- **Local development**: Individual developer environments for initial coding and testing
- **Continuous integration**: Automated testing of all code changes
- **Staging**: A production-like environment for final validation before release
- **Production**: The secure, monitored environment that serves actual customers

![Open Fabric deployment process workflow showing release stages](assets/openfabric-deployment.webp)

Our development process incorporated several best practices for distributed teams:

- **Trunk-based development**: Single main branch with short-lived feature branches
- **Coordinated releases**: Synchronized deployments across interdependent services
- **Design reviews**: Team discussions about architecture and implementations before coding
- **Automated deployments**: CI/CD pipeline for consistent and reliable releases
- **Incident management**: Clear procedures for handling production issues

### How we collaborated

Our 8-person engineering team became an extension of Open Fabric's own technical staff. We quickly assembled a team of specialists:

- Senior backend engineers with experience in high-performance financial systems
- Frontend developers who understood both UI design and backend integration
- DevOps specialists who could automate testing and deployment processes

We established clear communication channels for different types of interactions:

- Regular planning sessions for roadmap and feature prioritization
- Daily standups for progress updates and blocker resolution
- Technical design reviews for architecture decisions
- Code reviews for maintaining quality standards
- Joint on-call rotations for production support

This approach created a seamless working relationship regardless of physical location, allowing both teams to collaborate effectively whether in office or remote.

## What we achieved

Working with Open Fabric, we successfully delivered the core components of their payment platform:

- A robust central system that manages the entire payment ecosystem
- Web interfaces for merchants, payment providers, and administrators
- A secure multi-tenant architecture that supports different business types
- A complete working product that enabled market entry

Our partnership provided Open Fabric with several significant advantages:

- **Faster time to market** without compromising on quality or security
- **Achievement of business milestones** necessary for establishing their position in Southeast Asia
- **Technical team extension** without the overhead of extensive recruitment
- **Focus on product strategy** rather than infrastructure concerns

By providing experienced engineers who integrated seamlessly with their team, we helped Open Fabric invest more in product development while leveraging our technical expertise. Our team didn't just write code – we contributed to architectural decisions and process improvements that will support Open Fabric's growth for years to come.

The platform we built continues to evolve as Open Fabric expands to new markets and adds more payment options, built on the solid foundation established through our collaboration.


We helped Open Fabric build a payment platform that makes it easier for stores to accept digital payments across Southeast Asia. Our team built the core technology and delivered a working product within a year.

Open Fabric

Building a payment platform from scratch


**Industry**\
E-commerce Technology

**Location**\
United States / Global

**Business context**\
AI search startup needed to enhance their platform and developer tools

**Solution**\
Improved dashboard UI, developed open-source tools, and created better integration plugins

**Outcome**\
Delivered high-quality solutions that helped establish Search.io as a leader in AI-powered search

**Our service**\
Frontend development / UI/UX enhancement / SDK development

## Technical highlights

- **Frontend**: React.js with TypeScript for reliable interfaces
- **State management**: Redux for complex application state
- **Component library**: Custom UI components for consistency
- **Documentation**: Docusaurus for comprehensive developer guides
- **Testing**: Extensive unit and integration tests
- **Integration**: Custom plugins for various e-commerce platforms

## What we did with Search.io

Search.io (formerly Sajari) is an AI-powered search platform that helps online stores increase their sales through better product discovery. Founded in 2017, they create technology that makes it easier for shoppers to find exactly what they're looking for.

We worked with Search.io on three main areas: improving their main dashboard, enhancing their open-source tools, and developing better interfaces for their plugins. The project focused on creating reliable, stable solutions that Search.io's clients could depend on, rather than rushing to build features quickly.

Our development approach emphasized quality and stability, which aligned perfectly with Search.io's commitment to providing dependable technology that their customers could trust.

![Search.io platform dashboard showing the AI-powered search controls](assets/searchio-main.webp)

## The challenge Search.io was facing

Search.io's platform helps businesses perform better by providing advanced online discovery services. Their technology needs to understand what users are looking for (like a human would) while still being fast and available through easy-to-use interfaces.

The company wanted to make sure customers had a great experience no matter how they used the search tools - whether through Search.io's own dashboard or when integrated into other platforms. This meant creating developer-friendly tools and consistent interfaces across different systems.

They faced several technical challenges:

1. **Different user needs**: Their platform serves both business users managing search settings and developers integrating search into websites
2. **Multiple integration points**: The search functionality needed to work across various platforms and e-commerce systems
3. **Complex technology**: Their advanced AI search algorithms needed simple interfaces that non-technical users could understand

These challenges were particularly important as Search.io was looking to expand their market reach and compete with larger search providers.

![Search.io's technical platform architecture diagram](assets/searchio-context.webp)

## How we built it

Our work with Search.io covered three key areas, each requiring a different approach to solve specific problems.

### Technical approach

**Console Dashboard Improvements**: We enhanced the main control panel that businesses use to manage their search experiences. We focused on:

- Creating intuitive interfaces for configuring complex search algorithms
- Building visualization tools to help users understand search performance
- Streamlining workflows for common tasks like adding synonyms and adjusting relevance
- Implementing responsive designs that work well on different devices

**React SDK Development**: What began as a specific integration for Shopify evolved into Search.io's most important open-source offering. For this SDK, we:

- Built a flexible library that developers could easily customize for their needs
- Created comprehensive documentation with clear examples
- Designed a modular architecture that supports different UI frameworks
- Implemented automated testing to ensure reliability

**Platform Integrations**: We developed plugins for various e-commerce platforms, making it easier for stores to implement Search.io's technology. These integrations:

- Provided simple installation processes for non-technical users
- Maintained consistent functionality across different platforms
- Included customization options for advanced users
- Supported automatic updates to keep the search experience current

For the technical implementation, we used React.js with TypeScript to build reliable user interfaces. We implemented Redux for managing complex application state and developed a reusable component library to ensure consistency across all products.

Our emphasis on quality included creating comprehensive developer guides using Docusaurus and implementing extensive unit and integration tests to ensure reliability.

### How we collaborated

We established a collaborative process that worked well with Search.io's distributed team:

- Regular video calls to discuss priorities and review progress
- Shared design documents and specifications in Figma
- Code reviews through GitHub pull requests
- Slack channels for quick communication and problem-solving
- Joint testing sessions to identify and address issues

Throughout the project, we maintained close communication with Search.io's team, adapting our work to fit their evolving needs and ensuring that all deliverables met their high-quality standards.

## What we achieved

Our work with Search.io resulted in several important improvements that helped strengthen their position in the market:

- **Enhanced dashboard**: A more powerful and user-friendly console that gives businesses better control over their search experiences
- **Improved developer tools**: SDKs and libraries that make it easier for developers to integrate Search.io's technology
- **New integration options**: Support for additional e-commerce platforms, expanding Search.io's market reach

The Shopify integration we developed helped Search.io connect with one of the largest e-commerce platforms, opening up a significant new market segment. Meanwhile, the search widget we created offered an easy solution for websites with limited development resources.

A Product Manager at Search.io noted: "Working with the Dwarves team has been a game-changer for us. They not only understood our technical needs but also grasped the business impact of what we're building. Their focus on quality and attention to detail helped us deliver a more powerful platform to our customers."

Our partnership enabled Search.io to enhance their offerings and provide a more robust search platform that delivers real-time results and has become trusted by large businesses worldwide. The improvements we made helped establish Search.io as a leader in AI-powered search technology, giving them a strong foundation for continued growth.

By focusing on quality and user experience rather than just adding features, we helped Search.io create solutions that truly improved their customers' businesses and strengthened their competitive position in the market.


We helped Search.io improve their dashboard, enhance their open-source tools, and create better interfaces for their plugins, helping online stores boost sales with smarter search.

Search.io

Building AI-powered search for online stores


We use email as our formal tool for both internal and external communication.
Every email is utilized for a specific field, which comes along with different instructions.

We currently go with these:

### <team@d.foundation>

For external communication. Clients or people outside the company should only know this email to communicate with us. Every email composed by <team@d.foundation> should be meant for external contacts, such as agreement or announcement.

### <ops@d.foundation>

For internal communication. Everything happens in the company, the operation email should be in the cc. <ops@d.foundation> email is used to

- Inform employee on his/her employment issue (term of employment, salary adjustment, review, meeting)
- Log conversation with clients from other personal team accounts (through cc)
- etc

### <spawn@d.foundation>

For hiring. <spawn@d.foundation> stores every material used for the hiring process, which includes

- Invitation for tests ( Pre-Assessment/ Assignment)
- Receive _DO-NOT-REPLY_ notification from CCAT (our resource to assess applicant's competence )
- Confirmation/Reject email for applicants
- Job offer
- Automated receive CV from job sites

### <accounting@d.foundation>

As it sounds, <accounting@d.foundation> is all for the issue that relates to money transaction.

- Invoice information (in & out)
- Notification on employee salary adjustment (through cc from Operation)
- Tax

### <thug@d.foundation>

For Infras registration e.g. Cloudflare, Google Cloud, AWS ...


We use email as our formal tool for both internal and external communication. Every email is utilized for a specific field, which comes along with different instructions.

Email use

Email communication and use


## 1Password storage

Link to company 1Password: [https://dwarvesv.1password.com](https://dwarvesv.1password.com/). We have 2 accounts for 1Password usage:

- **Team account**: This should stores all of company's account and will be shared with the correspondent team members. To get access to this information, please contact your line manager OR Operation team. _This account should NOT be shared with people outside of D.F_
- **Operation account**: This account stores the confidential credentials that related to Operation team and should only shared to people within the Ops Team.

## Updating secret key

In order to keep the confidential information from leaking out, Operation team will continuously update the account's secret key overtime.

The latest key will be stored here: https://drive.google.com/open?id=1x2JzetR_8CkQcoHFo4J1U99zLynPZYmz

Master password will be sent out separately upon request


Password sharing


The annual bonus for sales are the sum of 2 portions

### New deals of current year

The annual will be calculated based on the total commission you earn that year. They are divided into 3 tiers as in the table above.

- Low: earn extra **$600 to $4k** for new deployment team size of **4 - 8 in 12 months**
- Medium: earn extra **$9k to $60k** for new deployment team size of **12 - 20 in 12 months**
- High: earn extra **$72k to $96k** for new deployment team size of **24 - 32 in 12 months**

### Previous deals

For previous deals, you will earn extra **2% of the old money commission**.

### FAQ

- Upselling is considered as new money


Guide to calculate annual bonus for sales

Annual bonus for sales


## For admin

### Lending

- [ ] Collect request on Basecamp at Woodland → To dos → Asset Request
- [ ] Check the status of the asset
- [ ] Have the borrower's information logged in Airtable
- [ ] Set a deadline for asset returning

### Collecting

- [ ] Collect the asset from the borrower
- [ ] Check the status of asset
- [ ] Report for damage caused (if any)
- [ ] Tick done on the To-dos ticket

## For employee

### Borrowing

- [ ] Request on Basecamp at Woodland → To dos → Asset Request
- [ ] Collect the asset from Admin/Ops Associate
- [ ] Report for damage (if any)
- [ ] Set up deadline for returning

### Returning

- [ ] Check the asset status
- [ ] Report for damage (if any)
- [ ] Sync up with the Admin/Ops Associate


This checklist is for administrators and employee to manage company's assets.

Assets


## Invoice process

### Person In Charge (PIC)

Person In Charge for invoice will be the person in charge of the Account, if the Account doesn't have any person in charge, other people in the Operation team will be in charge. Ideally, the second Person In Charge will be the Salesperson of the project.

For example: Nam will be the second person in charge of the Attrace account, as she is the Salesperson of this project

### Invoice statuses

- Every month, Fortress will automatically generate the invoices based on the previous month for the projects that are opening ( At this stage the invoice will be saved as Draft )
- During the 25th - 27th of each month, PIC will need to send out the Off-days report to Special Clients and seek out for their confirmation
- PIC will need to check the invoice content (Including member time-off)
- After received feedbacks from clients and reviewed all invoice contents, PIC will send the official invoice to client. ( Status will be changed to Sent )
- When Han receives the money transferred from client, he will change the invoice status to Paid
- If the invoice has not been paid 7 days after the send date, its status will be changed to Overdue . PIC will need to send a follow up email for the invoice
- In any case, if there are errors after the invoices have been sent to clients, we can mark the invoices as 'Error' and PIC need to send an email explains why the invoice is incorrect, and make a new invoice to resend to client

## Compliance check for invoice

### Issue an invoice

- [ ] Invoice shows the correct numbers of item price, total price
- [ ] Invoice has invoice date
- [ ] Invoice has due date (= invoice date + 7)
- [ ] Invoice has clear description to explain the item we charge client and any other important note to help them understand the invoice content
- [ ] Invoice has a note for important details (i.e: routing number, reference number..etc)

### Invoice status

- [ ] Invoice status must be up-to-date with the reality
- [ ] Invoice status is updated by the Person In Charge

### Sending

- [ ] Invoice is sent by the designated Person In Charge
- [ ] Error invoice must be notified to the Clients and marked as error in Fortress as soon as possible
- [ ] The Person In Charge have to follow up overdue invoice within 3 days
- [ ] After the payment is deposited in DF's account, an official confirmation will be sent to the Clients
- [ ] Invoice must be sent before or right on the monthly invoice date or after completing a payment milestone.


This checklist illustrates the process of billing approval.

Billing


### Background & skills

- [ ] Logic qualified
- [ ] English skills qualified
- [ ] Technical (specialized) knowledge & skills qualified

### Personalities

This [hiring practice](https://memo.d.foundation/playbook/operations/hiring-approach/) can tell

But we can have some shortcuts

- [ ] Doer
- [ ] Curiosity
- [ ] Problem-solving
- [ ] Learner
- [ ] Teamwork
- [ ] Open-minded
- [ ] Collaborative
- [ ] Supportive
- [ ] Any issues in previous works?
- [ ] Personality check via social?


The checklist will show how to evaluate a candidate.

Candidate


### Content

- [ ] The contract must be numbered incrementally according to the total number of contract in that year
- [ ] The contract must have paging
- [ ] The contract must have enough contractors information
- [ ] The payment term in the contract should be numbered and have concise description
- [ ] The currency, country, applicable law (Clause 18) needs to be updated accordingly
- [ ] The termination term in the contract should be reviewed carefully
- [ ] The features list or scope of work must be specified clearly (i.e the design, requirement documents must have version)

### Process

- [ ] Contract is signed legally by parties/people having responsibility (i.e [hellosign.com](http://hellosign.com/))
- [ ] Contract must be signed before initiate the project
- [ ] The final and signed contract is put on the Official folder on Drive
- [ ] The contract is stored on Drive including the final PDF and the final source file (i.e Word/Google Docs/Pages)


The checklist presents the process of contract evaluation.

Consulting contract


### Resume collecting

- [ ] Job Description
- [ ] List of job sites/hiring channels
- [ ] Job post materials
- [ ] Hiring system (Notion)

### Timeline

- [ ] Invitation & calendar send out (also the interviewer assigned?)
- [ ] Interview result after each round must be reported
- [ ] Responsive?
- [ ] Follow the process? Skip any round?
- [ ] Ignore or miss any applicant?
- [ ] Meet deadline for each round?
- [ ] Does the assignment grader carefully grade the applicant assignment?
- [ ] Conflict of interest? (Applied for the referral model)

---

- [ ] Deadline for application
- [ ] Time of interview
- [ ] Time of confirmation emails
- [ ] Time of on-boarding
- [ ] Time of probation

### Offering

- [ ] If a candidate is the right fit, move quickly
- [ ] Before you make an offer, make sure you know exactly what the offer package will look like and don’t be vague about it
- [ ] If the candidate turns you down, remain friendly and maintain a relationship. They might change their minds in the future.
- [ ] Enough information? (salary, probation, title, benefit, start date...)
- [ ] Are the department head, accounting, operation aware of the offer?

### Material

- [ ] Handbook
- [ ] Pre-assignment Test
- [ ] Assignment
- [ ] Templates for multiple scenarios


The checklist presents how the hiring is proceeded.

Hiring


Through this process, the employee gradually form their own perspective and their fit with the Dwarves. This is the stage when they decide whether or not to commit to our company.

![](assets/onboarding-checklist_onboard.webp)

## Important notes

- [ ] Starting on-boarding on the new hire’s first day
- [ ] Not setting expectations and company policies.
- [ ] Instituting a one-size-fits-all approach for every new hire.
- [ ] Involving only the new hire’s direct team or department.
- [ ] Limiting on-boarding to one week.
- [ ] Forgetting to follow-up.

## Offer email

An offer email should cover these points

- [ ] Net/gross salary
- [ ] Onboarding day

## Onboarding email

After sending the offer email and getting the confirmation from candidate, the onboarding email is sent to request users to complete the oboarding process which include

- [ ] Request setting up Transferwise and its acount number
- [ ] Request Identity card information
- [ ] [Insurance information](https://www.notion.so/IT-Security-Measures-Document-3eb7f8ee49b841038523304164291184?pvs=21)
- [ ] Fill the fortress form
- [ ] Sign the contract with LLC
- [ ] Create onboarding schedule
- [ ] Invite to Dwarves Foundation Discord server

## Onboarding call with Operations team

The Operation team make sure the new hire knows about his/her position, prepares his/her personal account for company access, and understands the daily workflow.

The newbie must also know how this company runs, benefits & perks, essentials paperwork, review period, and expectation for culture fit.

The onboarding call must introduce these information:

- [ ] The goal of the probation

- Team, Leader, and Project Introduction
- Personal 60 days plan

- [ ] Workspace Introduction

- Discord: Team's communication channel
- Basecamp: Task, document, and onleave request management

- [ ] Onboarding to Reward system (ICY)

- Create and connect crypto wallet to Dwarves Foundation server
- Create and connect github account to Dwarves Foundation server

- [ ] The team's workflow

- Daily report and check-in
- On-leave request and reimbursement
- Communication channels

The detail information for each section is shown below.

## Add new member to working space and communication channel

- [ ] Self-introduction in Discord. The introduction should include:

- How we should address you (name/nickname/English name)
- Your role at Dwarves
- Which project you will join
- What your goals are as a software engineer
- Ops: mention the teammates on Discord for a warm welcome

- [ ] Thanh/ Giang/ Ngoc/Huy onboard to project

## Meeting with team lead

### Probation Guideline (60-day plan)

- [ ] Goals and targets for 2 month probation period
- [ ] Schedule review date after 2 months
- [ ] Introduce the new hire to the department head
- [ ] Make sure he/she has a line manager/leader
- [ ] Understand the work scope & expectations
- [ ] Check-in for work exp & culture fit , Bi-weekly checkins

- First 2-weeks: Culture fit & workflow
- First probation: SOW & expectation
- Second probation: The next 6-month

- [ ] Engage and Share , Dwarves Activities. Share with the team about

- Technical topics
- News
- Practices & examples
- Assign topics for Radio Talk
- Apply & train for mentor/ coach


What we have to do when a new employee come to our team.

Onboarding


### When an employee ask for social insurance and contract

- [ ] Adjusted salary will be noted
- [ ] Notice to Quang & Han about salary adjustment

### Required documents

- [ ] Social Insurance number
- [ ] PIT number
- [ ] Household Registration Book
- [ ] ID card (photo)
- [ ] Number of inhabitants (photo)
- [ ] Declaration of Temporary ### Residence
- [ ] Labour Contract


The checklist of unemployment, social, health insurance

Unemployment, social, health insurance


### Invoice checklist

- [ ] Invoice Date must be increase with Invoice Number.
- [ ] Company Name, Tax Code, Address on Business Registration Form.
- [ ] Item must be identical to the contract .
- [ ] Include Contract number.
- [ ] VAT: use "/" in VAT fields.
- [ ] Sign on each sheet of the invoice, do not sign overlap.
- [ ] Mark on each signature
- [ ] Mark new address
- [ ] Send invoice to customer

### For error invoice

- [ ] Revoke the error invoices
- [ ] Clamp 3 sheets of the invoice


Vietnam invoice


Guidelines for project collaboration between Dwarves and our Clients.

## Tools

- Project management & communication: Basecamp (invited as Client)
- Sprint planning & tracking: Jira/Basecamp
- Meeting: Google Meet
- Source control platform: Github/Gitlab (self-hosted)
- Design: Figma/Sketch

## Schedule

- Project kick-off meeting: **1 session**
- Sprint length: **1 week**/**2 week**
- Sprint planning meeting: **1 per sprint**
- Sprint review & retrospective meeting: **1 per sprint**
- Sprint **daily standup** meetings (can as well be done via a communication channel or Basecamp's check-ins)
- Project/team feedback meeting (with Account Manager): **1 per week** or **1 every 2 weeks**

Meeting notes for Sprint planning and Sprint retrospective will be sent within 30 minutes after the meeting.

## Workflow

### Project management

- All team members must be involved in Sprint planning
- Milestones and features (epics) should be put on Jira/Basecamp during the Project kick-off phase
- New features/change requests will be put into Icebox/Backlog, estimated, and planned for future Sprints
- Bugs can be added to the current Sprint depends on priority, complexity, and available points of the Sprint
- The intention of every Sprint is “Potentially Shippable” Software, things can go wrong and features might get pushed to the next Sprint
- Every 2 weeks, the Team Lead, Product Manager/Project Manager, and Account Manager will have a quick 15 minutes meeting to review the work progress and resolve any conflicts (if any)

### Design <> development

- The design team should at least provide:
  - Color palette (all that are used throughout the UI)
  - Heading / Font size should be defined by scale (similar to [Tailwind's](https://tailwindcss.com/docs/font-size/#usage))
  - Base components (.eg headings, button variants, and states,...)
- A new design version is expected to be available and reviewed **by the development team** before the Sprint started

### Backend <> frontend

- Pre-requisite:
  - API versioning & documentation (.eg Swagger)
  - Dedicated environments for Development / Staging / Production
- Backend should enable CORS on either API gateway or at the application level
- Both sides should agree on the same glossary/naming conventions / data schema, preferably within the first Sprint

### Quality assurance <> development

- Bugs/issues raised should include:
  - Steps to reproduce, behaviorally described from application's entry to bug encounter
  - Affected platform, version, feature, language (if applicable)
  - Severity level
- For Frontend (web), each feature's Pull Request will have a dedicated environment for testing. Use it to run feature tests before it got merged

## Release

- We release the end of each Sprint (on Sprint wrap-up day - the day before the Retrospective meeting)
- Hotfix releases are ad-hoc
- What's included in a release:
  - Semantic version tagging
  - release notes, changelogs, known issues
  - release's artifacts
- Backend and Frontend (or each micro-service in the system) will be released individually based on the Semantic version

## Customer feedback

We received and response to feedback via direct message, email, or video calls. Specific feedback should be directed to specific PIC in a project team:

- Implementation/Development: Team Lead, Project Lead
- Sprint result: Project Lead, Account Manager
- Project progress: Project Lead, Account Manager
- Pricing/Billing: Account Manager
- Communication issues: Project Lead

## Issues management

We promise to respond and resolve in a timely fashion when problems arise, depends on priority & severity.

After issues were resolved, we will conduct an issue investigation and provide preventive measures (if applicable).

There are **4 levels** of severity:

### Critical: 4

The production system is down or a major function is unusable and there is no acceptable alternative method to achieve the required results. Support in such emergency issues is available via our hotline.

- Contact channel: hotline
- Response time: within 10 minutes
- Promised resolve time: less than 30 minutes

### Major: 3

Major features of the product are failed and/or performance issues impacting the normal functioning of multiple users.

- Contact channel: email, primarily communication channel
- Response time: within 30 minutes
- Promised resolve time: from 2 to 5 hours

### Moderate: 2

Moderate loss of application functionality or performance degradation. The system is still operating but doesn't meet promised standard operation.

- Contact channel: primary communication channel
- Response time: within 45 minutes
- Promised resolve time: within 7 hours

### Minor: 1

Minor issues such as visual incorrectness .eg color or font size, product feature requests, and how-to questions.

- Contact channel: primary communication channel
- Response time: within 1 business day
- Promised resolve time: within 1 business day

Subject to the above limitations, we promise to respond to support requests within twenty-four (24) hours.

## Billing

Through every month, our Accountant and Account Manager will compose and send invoices to our Clients during the **23rd-25th**. The total invoice will base on the deployed resources, whether the project type is Fixed-price or Time & Materials (T&M). This method will enable a constant monthly cost, allows the Accountant from both parties to control the project costs & budgets more efficiently, as well as helping the Project Manager to foresee and eliminate any arising miscellaneous fees.

Our rates are always recorded in **NET** amount, excluded from all types of taxes, bank fees, and account-related fees.

Our invoice will contain the necessary information for the Client to proceed with the internal approval and wiring requirements:

- Bank information
- Invoice description
- Invoice details

The Client will have **10** **(Ten) business days** to complete these invoices. If the Client needs to extend the payment deadline, the Client is required to submit a written request to Dwarves Foundation within *72 hours* after the invoice date. A new deadline then will be decided and agreed by both parties, before it can be implemented officially.

Our Accountant and Account Manager will send out reminders to the Clients who may have forgotten about the outstanding invoices. If any Client failed to complete the payment on time and failed to submit a request for an extended payment deadline to Dwarves Foundation, we will add a *10% interest rate/month* to the outstanding invoice(s).

## Project responsibility scope

To avoid us as a project team from stepping on each other's foot and to ensure a healthy relationship for the team and Client.

**Team lead**

- Main PIC of the offshore development team
- Define technical stacks (together with the Client's team, if applicable)
- Main PIC of project's infrastructure (if applicable, there are cases where infrastructure is managed/provided by Client's team)
- Daily/bi-weekly/weekly progress sync-up and report to Client
- Receive, discuss and make plans for project milestones
- Run the development Sprint with offshore team and Client

**Account Manager**

- Receive Client's direct feedback
- Make improvement plans for the offshore team from provided feedback
- Maintaining the relationship between both sides
- Ensuring development time, workforce and workload maps accurately to the Client's budget

**Project Manager?**

- Designing and applying appropriate project management standards
- Managing the production of the required deliverables, and project administration
- Adopting any delegation and use of project assurance roles within agreed reporting structures
- Managing project risks, including the development of contingency plans.
  liaison with program management (if the project is part of a program) and related projects to ensure that work is neither overlooked nor duplicated.
- Monitoring overall progress and use of resources, initiating corrective action where necessary
  applying change control and configuration management processes.
- Reporting through agreed lines on project progress through highlight reports and end-stage assessments.
- Liaison with appointed project assurance representatives to assure the overall direction and integrity of the project.
- Maintaining an awareness of potential interdependencies with other projects and their impact
  adopting and applying appropriate technical and quality strategies and standards
- Identifying and obtaining support and advice required for the management, planning and control of the project.
- Conducting a project evaluation review to assess how well the project was managed
  preparing any follow-on action recommendations


Guidelines for project collaboration between Dwarves and our Clients.

Collaboration guidelines


## Compliance checklist

Compliance master list is stored [here](https://docs.google.com/spreadsheets/d/16HtA3skVpEdDpuJ9UEkPb5Ae_SK6IiJ5Czfl_94XqN4/edit#gid=449337167).

## Compliance execution

Compliance check will be done in the monthly basis:

- Each month compliance team will pick 30% projects to execute compliance checklist.
- The master compliance checklist will be cloned to another file and name as df-compliance-<field-where-executed>-<yyyy><mm>. The file will be stored at same root folder with the master checklist.
  Example: _df-compliance-project-201905_.
- Each file will contain the sheets for each project that being checked.
- Compliance PIC will create a todo on Basecamp and assign to the PICs of those projects.

## Result verification and action

- After the compliance checklist is completed by the PIC of the project, compliance individual will do the clarification round by either:
  - Sit with the PIC to ask questions about the result of the checklist.
  - Assign the checklist for another team member of that project and compare the result.
- PIC of the project will be responsible for the actions to fix the problems discovered during the compliance check session.
- Compliance report will be produced by compliance PIC and will be presented to the whole team during engineering meeting.

## Fame or shame

- Projects that have a good measurement in the compliance session will have "Fame" (TBD)
- Projects that have a bad measurement in the compliance session will have "Shame" (TBD)
  - If you have completed the compliance checklist but failed or cannot explain some categories, it is REQUIRED that you need a proper training on that topic.
- Compliance checklist will be mandatory for the newcomers in order to pass their probation period.

---

I think the bottom line is what we aim to "audit" - our first attemption to audit (sometimes last year) was mostly technical, and we didn't run it seriously thus it ended in void (.eg none cares to fix raised issues).

Now that I think about it, and after seeing what happened in setel, the most important thing to run these kind of program is to be transparent AND clearly point out action points & consequences.Transparent here means everyone knows about it .eg what/why/how as well as implicitly aware the consequences of not progressing as planned (bad ranking? khai trừ khỏi đ?ang?)almost all similar audits in Setel happened like this:

1. announcement (why/what/how/expected outcome)
2. progress tracking at team level (which team has done, in progress or no progress)
3. weekly progress announcement & call to action
4. why a team has not started? ask TL for reason & ask him to come up with a plan/tasks
5. all done, announcement of completeness & outcome, phát phiếu bé ngoan

We can leverage 2-3 to put an invisble heavy stone on someone's back for having to plan it himself to do it properly.

Also it should be noted that all above 5 points above happened publicy - which helps to enforce individuals to aware & participate - seeing others progressing while I don't even know how to do it is a real stress, forcing me to proactively ask/lookup for more info. That's where work begins, with consistency it can educate members to fit in our workflow.


A comprehensive compliance program encompassing monthly audits, transparent progress tracking, and consequences for non-compliance, aiming to foster accountability and transparency within the team.

Compliance check process


**Title:** Dwarves Foundation - Assignment Invitation

**Body**

Hi [**name**]

Congratulations on reaching the second round for [**position**] position.

To better match your potential with our role, we would like you to complete a small exercise at [**link**]. This helps to demonstrate how you approach the tasks and provide us with some points to begin the interview.

Please submit your completed assignment by [**date**].

Feel free to let us know if you have any other questions about the assignment.

Sincerely,
Dwarves Foundation


The email template is to invite camdidate to the assignment round in case the pre-assessment is skipped.

Assignment Inviation (Skip pre-assessment)


**Title:** Dwarves Foundation - Assignment Invitation

**Body**

Hello [**name**]

Congratulations on passing our Pre-Assessment test for [**position**] position.

To better match your potential with our role, we would like you to complete an assignment at [**link**]. This helps to demonstrate how you approach the tasks and provide us with some points to begin the interview.

Please submit your completed assignment to us by [**date**].

Feel free to let us know if you have any other questions about the assignment.

Sincerely,

Dwarves Foundation


The email template is to invite camdidate to the assignment round.

Assignment inviations


**Title**: Dwarves Foundation - Welcome Back

**Body**

Dear [**employee name**],

Warmly welcome you to come back with us. We hope you have had all the things arranged perfectly.

This email is to confirm your returning to work with these below details:

- Resume date:
- Office hours:

Please be reminded that your benefit package will remain the same. We understand it might take some time to catch up with other members. Please take any time you need to get back with the chase and impress us with your enthusiasm.

On behalf of other Dwarves, it’s good to have you back!

Best regards,
Dwarves Foundation


The email template is to welcome employee back to work.

Confirm employee's resume date day


**Title**: Dwarves Foundation - Farewell letter

**Body**

Hi [**name**],

On behalf of DF, we would like to express our gratitude for contribution in the last three months.

However, we are regret to inform that your probationary period at DF will be concluded since your performance cannot meet our expectation. Still, we want to thank you for spending your time and effort being a part of the team.

We encourage you to re-apply for any of our next vacant positions in your expertise area. In the mean time, may all the good luck will come to you in your next endeavor.

Thank you,
Dwarves Foundation


The email template is to inform employee that he/she failed the probation.

Farewell letter


**Title:** Dwarves Foundation - Holiday Announcement

**Body**
Dear [**company name**],

Dwarves Foundation would like to thank you for your kind cooperation during the time.

In the history of Vietnam, we annually hold a ceremony on the 10th day of the 3rd lunar month. The purpose of Hung King commemoration day is to remember and express our gratitude to the contribution of the Hung Kings - who are known as the traditional founders of the nation and became its first emperors.

According to the Government’s regulation about the public holiday [**year**], we are pleased to inform the schedule of the holiday as follow:

_Dwarves Foundation will be closed from_ <-date-> _to the end of_ [**date**]_. We will resume our normal business hours on_ [**date**]_._

Please note that all the queries and orders should be requested at least **3 days up to 1 week before** the holidays starts. Any further riddle within this time shall be promptly processed as soon as we join back.

In case of emergencies or critical issues, please WhatsApp **(+1)** **818 408 6969**.

We sincerely apology for any inconvenience this may cause.

Thank you for your understanding.

Best regards,

Team Dwarves


The email template that you need to send to client when it's near holiday to announce about the absence.

Hung King commemoration day


**Title:** Dwarves Foundation - Resource Changes Agreement on [**Name of Project**] from [**date**]

**Body:**

Dear [**customer name**]

Thank you for your kind collaboration with us on the [**Name of Project**].

According to the consultancy agreement no [**CA Number**] we signed on hellosign.com, this email confirms the changes in the development services which is specified in the Services term in the Appendix 1.

We are presently in the process of [**stage of process**] with the current resource of

- Position of Devs
  This email is to inform you about our changes in resource in order to meet the requirements on both sides from [**date**]. The new resource for [**Name of Project**] shall be updated as below

- New resource
  As a result, the status of the resources going forward from [**date**] with this following details

- Updated resource
  We do hope this change brings better fit the mutual requirements.

Please kindly confirm your agreement for this by providing us with your response email. Shall you have any idea on the changes, please let us know.

Best regards,

Team Dwarves

**Example**

![](assets/information-about-resource-change_template-resource-change.webp)


The email template that you need to send to client when it's near holiday to announce about the resource changes.

Inform about resource change


**Title:** Dwarves Foundation - Holiday Announcement

**Body**
Dear [**company name**],

Dwarves Foundation would like to thank you for your kind cooperation during the time.

In the history of Vietnam, April 30th, 1975 is the day that marks the fall of Saigon Government, ending the Vietnam War and leading to the liberation of Vietnam's Southern part.

Since this followed by the International labour day - May 1st - we are pleased to inform the schedule of the holiday according to the Government’s regulation about the public holiday [**year**]:

_Dwarves Foundation will be closed from_ [**date**] _to the end of_ [**date**]_. We will resume our normal business hours on_ [**date**]_._

Please note that all the queries and orders should be requested at least **3 days up to 1 week before** the holidays starts. Any further riddle within this time shall be promptly processed as soon as we join back.

In case of emergencies or critical issues, please WhatsApp **(+1) 818 408 6969**.

We sincerely apology for any inconvenience this may cause. Thank you for your understanding and we hope you find the holiday enjoying every single minute.

Best regards,
Team Dwarves Foundation.


International labour day


**Title:** Dwarves Foundation - Interview invitation

**Body**

Hi [**name**],

Thank you for applying to Dwarves Foundation as a [**position**]

This email is to remind and confirm your interview schedule. This is a 60-minute interview with detail as below:

- Time: DD/MM/YYYY - HH:MM AM/PM
- Location: Floor 18, Block Iris 3, Ha Do Centrosa, 118 3/2 street, District 10, HCMC.

Please park your bike in the basement. Once you get to block Iris 3, use the elevator to go to the 1st floor. Then contact our HR: Van - 0979291600

Note: Please bring your laptop for some quick assignment.

Hotline: 0282 246 0 246

Just let us know if you have any question about the interview. We looking forward to hearing from you.

Best regards,
Dwarves Foundation


The email template is to annouce the interview date with the client.

Interview invitation


**Title:** Project XX - Milestone Signoff

**Body:**

Dear [**Name**],

As discussed in previous meeting, we have agreed to sign off the last milestone [**name of milestone**] of [**project**]. Please help us to confirm on this email, upon confirmed we will send another invoice email.

Thank you for your collaboration.

Sincerely,
Dwarves Foundation


The email template is to confirm about the milestone with client.

Milestone sign-off


**Title:** Dwarves Foundation - Holiday Announcement

**Body**

Dear [**receiver name**],

Dwarves Foundation would like to express our gratitude toward your kind cooperation during the time.

**Vietnam National day** is held on September 2 to commemorate the Vietnam Declaration of Independence from France on September 2, 1945.

According to the Government’s regulation about the public holiday 2019, we are pleased to inform the schedule of the holiday as follow:

_Dwarves Foundation will be closed_ from [**date**] _to the end of_ [**date**]. _We will resume our normal business hours on_ [**date**]_._

Please note that all the queries and orders should be requested at least from **3 days up to** **1 week before** the holidays starts. Any further riddle within this time shall be promptly processed as soon as we join back.

In case of emergencies or critical issues, please contact **(+84)** **282 246 0246**.

We sincerely apology for any inconvenience this may cause. Thank you for your understanding.

Best regards,

Team Dwarves.


National day


**Title**: Dwarves Foundation - Holiday Announcement

**Body**

Dear [**company name**],

Dwarves Foundation would like to thank you for your kind cooperation during the time.

New Year's Eve and New year day have always been the time that everyone is looking forward to and we are no different from you. It is the symbol for festivities to say goodbye to the last year and mark the start of the new one.

According to the Government’s regulation about the public holiday [**year**], we are pleased to inform the schedule of the holiday as follow:

_Dwarves Foundation will be closed from_ -date- _to the end of_ [**date**]_. We will resume our normal business hours on_ [**date**]_._

Please note that all the queries and orders should be requested at least **3 days up to 1 week before** the holidays starts. Any further riddle within this time shall be promptly processed as soon as we join back.

In case of emergencies or critical issues, please contact (+**84**) **282 246 0246**.

We sincerely apology for any inconvenience this may cause. Thank you for your understanding and we genuinely hope you enjoy the holiday to the fullest.

Best regards,
Team Dwarves


New year day


**Title**: Dwarves Foundation - Offer letter

**Body**

Hi [**name**],

Thank you for your interest in the [**position**] position and your effort of taking the interview process at Dwarves Foundation. Based on the good performance after all, we are glad to see you as a good fit for the team.

As a result, we are pleased to offer you the position of [**, position**]-[**name,**] with the detail as below:

- Employment type: Full-time/Part-time
- Office hours: 9.30am - 6.30pm
- The GROSS salary : [**salary**] VND/month
- Probation time : [**probation duration**] months
- Probation salary: [**salary**] VND/month
- Commencement date: [**start date time**]
- Contract signed with LLC

Please confirm if your acceptance by replying to this email. Also, please let us know if the commencement date well fits your schedule.

We look forward to having you in the team!

Best regards,

Dwarves Foundation


The email template is to annouce about new employment.

Offer letter


**Use case**: Whenever a Dwarves refers to a teammate that successfully deployed to a project, we use this template to announce the official start date of their referral bonus.

**Title**: Dwarves Foundation: Referral bonus confirmation note

**Body:**

Hi [name]

This email is to confirm your referral bonus for the referring case of

We’re glad to announce that [referred employee] has been successfully deployed. As in the [Referral bonus policy](https://github.com/dwarvesf/handbook/blob/master/how-we-hire.md#referral), your referral bonus will be as followed:

- Referral bonus amount: [$]

_Please be noted that this bonus will be included into your monthly payslip and will be paid upon completion of the project invoice._

Thank you for helping us meet another cool teammate. If you have any questions regarding the effective date, please let me know.

Regards,


Whenever a Dwarves refers to a teammate that successfully deployed to a project, we use this template to announce the official start date of their referral bonus.

Referral bonus confirmation note


### Screening rejection

**Title**: Dwarves Foundation - Application Result

**Body**
Hi [**name**],

We really appreciate your interest in Dwarves Foundation. However, we’re sorry to inform that this position might not be the best match for you at the moment.

It was a pleasure to learn more about your skills and accomplishments. We will be keeping your CV on file for future openings that better fit your profile.

Meanwhile, we welcome you to come hangout at [**Dwarves Discord**](http://discord.gg/dfoundation), or stay tuned with our daily updates in [**Dwarves Fanpage**](https://www.facebook.com/dwarvesf).

We wish you all the best in your future endeavors.

Best regards,

Dwarves Foundation

### Interview rejection

**Title**: Dwarves Foundation - Interview Result

**Body**

Hi [**name**],

We really appreciate your time for the interview at Dwarves Foundation for the [**position**] position. However, we’re sorry to inform that this position might not be the best match for you at the moment.

It was a pleasure to learn more about your skills and accomplishments. We will be keeping your CV on file for future openings that better fit your profile.

Meanwhile, we welcome you to come hangout at [**Dwarves Discord**](http://discord.gg/dfoundation), or stay tuned with our daily updates in [**Dwarves Fanpage**](https://www.facebook.com/dwarvesf).

We wish you all the best in your future endeavors.

Best regards,

Dwarves Foundation


The email template is to reject a candidate that is not qualified in the recruitment process.

Rejection


**Title:** Dwarves Foundation - Salary Increment

**Body**

Dear [**name**],

As mentioned earlier, your amazing performance as a [**current position**] did reveal an impressive dedication that greatly impacted our objectives and long term goals.

It gratifies us to officially inform you on your salary increment with details as follows:

- Current salary:
- New salary:
- Effective day:

On behalf of other Dwarves, we want to extend our warm congratulations. Its a fortune to have you in our team and we hope to do so for years to come.

Best regards,
Dwarves Foundation


Salary increment announcement


**Title:** Dwarves Foundation - Holiday Announcement

**Body**

Dear [**company name**],

Dwarves Foundation would like to thank you for your kind cooperation during the time.

Tet holiday, or Vietnamese Lunar New Year, is the most important public holiday in Vietnamese culture. We celebrate the arrival of spring based on the Chinese Calendar by visiting relatives and family reunion.

According to the Government’s regulation about the public holiday -year-, we are pleased to inform the schedule of the holiday as follow:

_Dwarves Foundation will be closed from_ [**date**] _to the end of_ [**date**]_. We will resume our normal business hours on_ [**date**]_._

Please note that all the queries and orders should be requested at least **3 days up to 1 week before** the holidays starts. Any further riddle within this time shall be promptly processed as soon as we are back at work.

In case of emergencies or critical issues, please contact (**+84**) **282 246 0246**.
We sincerely apology for any inconvenience this may cause. Thank you for your understanding.

Best regards,
Team Dwarves


Tet holiday


**Title:** Dwarves Foundation - Thank you Letter

**Body**

Dear [**company name**],

We would like to express our gratitude towards your invaluable cooperation this whole time.

Thank you for working and entrust us with [**type of service we offer**]. We value your credibility in Dwarves Foundation and we do hope the outcome of the work did meet your expectation.

It has been a great pleasure having you as a steady partner during this project. Quality and customer service are what distinguish us from others. Your continued patronage and suggestions are the vital parts of our growth and we are grateful for that.

We look forward to having our paths crossed again and genuinely we wish you an amazing journey ahead.

Best regards,

Team Dwarves


The email template is to show appreciation to partner after the project closed.

Thank you letter


**Title**: Dwarves Foundation - Welcome onboard

**Body**

Hi [**name**],

Thank you for accepting the offer to join Dwarves Foundation as a [**position**]. It is our pleasure to welcome you to the team with the following details

- Onboarding date:
- Onboarding time: 10:00AM
- Onboarding link: -Google Calendar link-

_During this pandemic, you're welcome to start your first day at home._

Please help to fill out these following information so we can proceed with the Contract Agreement:

- A photo of your ID/Passport
- A digital copy of your portrait/ avatar (clean background, black/white t-shirt)
- Your current home address
- Your bank account information
- Your phone number
- Your current MBTI type. _If you haven’t taken the MBTI test, please do at [**this link**](https://www.16personalities.com/)_

We are looking forward to working with you. Do not hesitate to contact us if you have any further questions.

Best regards,

Dwarves Foundation


The email template is inform new employee about the onboarding meeting and information request.

Welcome onboard


Hey there!

You’re receiving this because you’ve interacted with Dwarves Team through our [website](https://dwarves.foundation/), our [Facebook](https://www.facebook.com/dwarvesf) posts, or the active [Discord Network](https://discord.gg/dfoundation?fbclid=IwAR0qISIXoxthRyof3yka_P12oWH6ixd5RVwCXBWna5NYJpgqho0M0zRIN8M).

No matter which platform you’ve stopped by, we thank you for doing that! Welcome to **Dwarves Updates**.

**Dwarves Updates** is where we share our lesson learned, where we head to and what we stay proud of - as a team. Short enough for your morning coffee, and get delivered once every month.

Dwarves Foundation is an innovative tech firm. We help business resolve their problem using tech solutions, offshore development and technical consultancy.

We simply want everyone who visits Dwarves Team can somehow be a part of our journey. It’s the companion that makes the road enjoyable.

Got a minute? Let’s walk through some of our previous issues at [**log.d.foundation**](https://log.d.foundation/)

- [**It’s a wrap: 2021 in Review**](https://log.d.foundation/ae3b921059ec4834b2f28195f71aee5f)
- [**Nov 30: Engineering organization structure**](https://log.d.foundation/06d0a46163914f10831d3146867dde2d#6fc9a667168242bb8b50990293562996)
- [**Oct 31: The path to growth at dwarves**](https://log.d.foundation/06d0a46163914f10831d3146867dde2d#3c1fa5109e9643ab9ca31c5fcc3a3a5c)

_In case this email doesn’t suit your need, please kindly unsubscribe here. Hope to see you again real soon._


The email template is to announce every updates to the comminity and subscriber.

Welcome to dwarves updates


## Email

- Email convention: <first_name><last_name_alias>@d.foundation
- - Example: <huytq@d.foundation>
    -- Exception: Operations members with frequent communication will use <first*name>@d.foundation instead. Example:*<han@d.foundation>\_
- Google Profile need to be filled with github id OR name: <first_name> <last_name>

![](assets/naming-convention_email-naming.webp)

## Basecamp

- Photo with your face picture
- Name: <first_name> <last_name>
- Title: Title at Dwarves Foundation

## Slack

- Avatar: Prefer that you put your face picture on
- Fullname: Your full Vietnamese name. Example: Tiêu Quang Huy
- Display name: Suggest to put your github id if you are a developer. Otherwise you can use <first_name> <last_name>
- What I do: Your role @ dwarves foundation

![](assets/naming-convention_slack-naming.webp)

## Trello/Jira and other project tools

- Advised to set avatar as your face picture.
- Name/Nickname should be set as your github name. Otherwise please use <first_name> <last_name>


This is the guide how to name your Email, Basecamp, Slack, Trello username.

Naming convention


## To turn on Gmail Canned Response (Template)

- Login to your Gmail account
- Access to Settings -> Settings -> Advanced tab
- Change Canned Responses (Templates) to **Enabled**

![](setup-email-template.webp)

## Adding/Using new template

When composing an email, you can either:

- Save the current draft as template for using later OR
- Pick a template to use for the email that you picked

**Note**: If your template contains place holders, please mark it as _red_ so that other team members will notice to replace those when they use the template


Setup email template in Gmail


![](assets/use-go-selenium-to-crawl-data_f963144e3cfac24481dbfeb02cf6a0e6_md5.webp)

## Crawl data

Crawl is a widespread issue occurring in making software. News, discount news, film ticket, etc are some examples of crawl. To be simple, it is analytics HTML, read cards, and extract data. The Go library I usually use is [goquery](https://github.com/PuerkitoBio/goquery).

However, crawling an original HTML will not work in some cases: data loaded by ajax (when reading HTML, we will only see wrapper, not data), or must login when entering a page need crawl.

In this article, take crawling [Amazon deal](https://www.amazon.com/gp/goldbox/all-deals/ref=gbps_ftr_s-3_3022_wht_541966?ie=UTF8&*Version*=1&*entries*=0&gb_f_GB-SUPPLE=sortOrder%3ABY_SCORE%2CenforcedCategories%3A3760911%2C2335752011%2C541966&pf_rd_p=2292853022&pf_rd_s=slot-3&pf_rd_t=701&pf_rd_i=gb_all&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=14CQSB5TF4GTC2RNHDAG) into consideration. In this page, javascript will call ajax taking data and then pour it into DOM. When using goquery read HTML, we will not see div cards like inspecting elements.

To these types, I use selenium to run the web in a real browser, take action to have fully loaded HTML before extracting data.

Selenium running in JVM is quite famous in automation test. It allows me to run script test in a real browser. My method will be: Use selenium to run the Amazon page, wait for javascript to load, and then crawl the data normally.

## How to setup

Firstly, you go to [seleniumhq](https://selenium.dev/downloads/) link to download and set up seleniumhq. Selenium plays a role like a server, receiving requests sent from my code Go.

To run it, we go to the folder containing file jar and run the command:

```plain_text
java -jar selenium-server-standalone-2.50.1.jar -port 8081
```

![](assets/use-go-selenium-to-crawl-data_79536b2784ffffd405fdcbd54b56927f_md5.webp)

\=> We have server selenium running at port 8081. Next, you pull Go-selenium in by Go get:

```javascript
go get sourcegraph.com/github.com/sourcegraph/go-selenium
```

After that, we need to set up a browser. I choose Firefox. Remember, when running locally, we only need to set up Firefox on the web. In contrast, running on the host we need to set up Firefox by Shell script. You can refer to [how to set up Selenium on Ubuntu 14.04](https://gist.github.com/curtismcmullan/7be1a8c1c841a9d8db2c) Done! Now let’s code.

We need:

- Remote to server selenium
- Access to Amazon deal link
- Conduct analytics HTLM to get information. I will print page title and the image of the first product

```javascript
func main() {
    var webDriver selenium.WebDriver
    var err error
    // set browser as firefox
    caps := selenium.Capabilities(map[string]interface{}{"browserName": "firefox"})
    // remote to selenium server
    if webDriver, err = selenium.NewRemote(caps, "http://localhost:8081/wd/hub"); err != nil {
        fmt.Printf("Failed to open session: %s\n", err)
        return
    }
    defer webDriver.Quit()

    err = webDriver.Get(URL_AMAZON_DEAL)
    if err != nil {
        fmt.Printf("Failed to load page: %s\n", err)
        return
    }
    // sleep for a while for fully loaded javascript
    time.Sleep(4 * time.Second)
    // get title
    if title, err := webDriver.Title(); err == nil {
        fmt.Printf("Page title: %s\n", title)
    } else {
        fmt.Printf("Failed to get page title: %s", err)
        return
    }

    var elem selenium.WebElement
    elem, err = webDriver.FindElement(selenium.ByCSSSelector, "#widgetContent")
    if err != nil {
        fmt.Printf("Failed to find element: %s\n", err)
        return
    }

    var firstElem selenium.WebElement
    firstElem, err = elem.FindElement(selenium.ByCSSSelector, ".a-section .dealContainer")
    if err != nil {
        fmt.Printf("Failed to find element: %s\n", err)
        return
    }
    // get image
    image, err := firstElem.FindElement(selenium.ByCSSSelector, "img")
    if err == nil {
        img, _ := image.GetAttribute("src")
        fmt.Println(img)
    }
}
```

Run the code, we have

```javascript
Page title: Gold Box Deals | Today's Deals - Amazon.com
https://images-na.ssl-images-amazon.com/images/I/51eU5JrGAXL.\_AA210\_.jpg
```

Well, we got all the needed information.

## Conclusion

Above is my knowledge when having problems with crawl in developing software. Here is Go software programming language. Selenium also helps us in other cases, like pages need login, web pages request captcha, etc. If anyone has other experiences, I hope to hear from you.


Learn how to use Go with Selenium to crawl dynamic web pages, overcoming challenges like AJAX-loaded content and login requirements. This guide demonstrates setting up Selenium, writing Go code to interact with web elements, and extracting data from Amazon's deal page.