White-labelling (Part 2): how Agoda manages development environments for white labels

In the previous part, I explained Agoda’s white label architecture, what they are, and how we manage the differences between white labels. If you haven’t read the first part, you can read it here — Building and scaling different travel websites with one codebase

To briefly recap: a white label is another travel website that uses Agoda’s code. We maintain the differences between websites by using a combination of White Label Service and Behaviour Management.

In this article, I will share how we address a challenge of multiple environments for multiple white labels: Development, QA, Pre-Live, Live/Production.

Multiple Environments for Multiple White Labels

At Agoda, we have different environments for development stages. We have URLs for each environment, development.agoda.com, testing.agoda.com, pre-live.agoda.com, and agoda.com, respectively. For each stage, there is a URL for every active pull request. For example, pull1234.pre-live.agoda.com is the pre-live URL for pull request #1234.

The challenge is that when we have created a pull request, developers have to check the website for other white labels. There must be a way for developers to access those white-label websites. Also, the system has to be able to present the website in different stages of the development process.

Using domain names for white labels

Our initial solution was to create a new domain for every white label. For example, for white label 42, assuming the name is Adoga, we would register a domain called notyetadoga.com for this white label.

We would then use the following approach for building a domain name:

• a subdomain for each stage of the development process, e.g., development.notyetadoga.com to indicate the development stage
• a sub-sub domain to represent a pull request, e.g., pull1234.pre-live.notyetadoga.com for pull request #1234.

As you can guess, the domain name solution works fine for the first few white labels. We eventually ran into multiple scalability problems, for example:

• The costs of creating and renewing the domain names and certificates
• Cross-Origin Resource Sharing (CORS) issues when forcing API endpoints on other domain names, etc.

In the end, we decided to move on from this high-cost and unscalable approach.

Using a header for white labels

Essentially, to differentiate white labels, we need to find a way to tell our server which white label ID we are trying to access. We then came up with the header solution.

Instead of using domain names, we can just send a custom header to our server-side to select what white label we want to get. For example, if we want to get white label 42, we can send the header x-agoda-whitelabel-id = 42 along with the requests using a browser extension, for example, ModHeader, etc.

When the reverse proxy receives the x-agoda-whitelabel-id header, it passes on that header downstream to the web server and other services. Those services use the header to get the configuration from White Label Service and compute the results.

This is a simple and scalable solution but does not work as expected on mobile devices. Furthermore, we cannot detect brand leakage (an accident that a white label shows images, links, or strings from another white label) with this approach because every white label still points to agoda.com. We can never know which URL/link points incorrectly.

In a typical development process, developers use mobile view in the browser’s dev tools to simulate viewing the website on mobile devices which work fine 99% of the time. However, in some cases, we found a bug that can only be reproduced on real mobile devices. Forcing the header on mobile devices is highly inconvenient and challenging. Also, it is difficult for our partners to look at the website since they might not have the technical background to know about headers and how to force them, which is a bad experience.

Even though the white label header is a much better approach than creating individual domain names, it is not very practical to do testing on mobile devices and troublesome for our partners and our automation test systems to test. We, again, had to find a new solution.

Back to domain names, but this time, it’s better!

We have observed a few problems with the previous solutions that we have faced:

• Overheads in preparing for a new white label
• No consolidated system for end-to-end (E2E) tests for white-labels
• Difficulties for the partners to access the website for user acceptance test (UAT)

The white-label team has designed a solution that combined both the header and domain name solutions with those problems in mind. We created another layer of a reverse proxy that works as follows:

• We created a unified white label domain name, agoda-whitelabel.com
• We added another layer, white-label proxy, to resolve the new white label URL scheme
• The white label reverse proxy tokenises the URL and maps back to the corresponding pull request, white-label, and environment
• The white label proxy then passes the mapped information to the reverse proxy to prepare information for the downstream systems

The URL scheme works as follows: for each environment, we use a subdomain to specify the white label, e.g., wl999.agoda-whitelabel.com for white label 999. We use the sub-sub domain name to target a pull request and environment, e.g., pull1234-pl.wl999.agoda-whitelabel.com for pull request #1234 on the pre-live environment for white label 999.

Initially, we considered having only one level of subdomain name, e.g. pull1234-pl-wl999.agoda-whitelabel.com to simplify the SSL certification management, but we realised the complexity and headache of cookie management that would follow. So, we decided to add one more level of subdomain name.

The current solution allows the system to be more flexible and extensible. We could add more environments easily. For example, uat.wl999.agoda-whitelabel.com can be used for user acceptance tests. This is much simpler for our partners and us to test the website.

Final Thoughts

To look back, we have learned a lot along the way. We combined the knowledge of two previous solutions, domain names and headers, to create the best solution so far. Of course, in software development, this is not the perfect and final solution. We are improving the domain name systems to support other environments, such as origins and different testing environments.

Next time you book a hotel or flight, you might be booking on Agoda’s partner websites unknowingly. Look out! It might be one of Agoda’s white labels if it is full of features!

Thanks to Vlad Batushkov, Kevin Kenny, Brinda Krishnan, Patthaphol Kulthawaiporn for their help improving this series.

Managing and scaling different white label development and testing environments was originally published in Agoda Engineering & Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

White-labelling (Part 1): the secret tool that enables Agoda to build multiple travel websites for our partners

Did you know that Agoda uses its code to create websites for other online travel agencies as well? We do this by using a process called white-labelling. When Agoda decided to white-label our website, we faced numerous challenges like — maintaining differences between websites, creating environments for different development stages, and more.

I have been working as a full-stack engineer at Agoda for around two years working on several white label projects on the accommodation, YCS, and flight funnels. I take the opportunity to share my experience in this two-part series of Agoda's successful model of white-labelling. By the end of this blog, you will have a clear understanding of how white-label looks from the inside, how it works on the code level, application, and different environments. I will do this by taking real-life examples of Agoda’s challenges with white-label and how we tackled them. Feel free to adapt the techniques I share with your team and organization.

What is White-Labelling?

While shopping online, have you noticed that some products are surprisingly similar? The similarities might be in terms of features or looks and feel. One of the most straightforward examples is mobile phones. Remove the labels, and the products look the same! Some brands use the same model of devices from the same assembly line but customize the User Interface to fit their branding. This process is called white-labelling.

In the software world, white-labelling is common. It is born from the idea that you make a product once and help your partners build their products by sharing your existing code with them and adjusting your product’s characteristics such as features, themes, etc., to suit their needs. Agoda saw this as an opportunity and decided to make our website a white-label ready brand.

Now that we understand white labelling and its importance let me show you how we implement it.

Agoda's Architecture Simplified

The first step is understanding Agoda's architecture. When a user lands on agoda.com, the reverse proxy resolves and maps the URL to determine the downstream systems or services to direct the request. For example, if a user requests agoda.com from their mobile device, it determines that the phone web server responsible for downstream service should receive this request.

After the request has reached either the desktop or mobile webserver, the webserver takes the information from the request to build and render the client-side. The webservers also connect to the white label service, which we are going to look into the details later on, and other backend APIs.

Resolving a White Label from a URL

Our white labels (partner websites) use the same infrastructure and codebase as Agoda. How can our system figure out which white label it is when a user visits one of the white labels?

The reverse proxy spearheads the responsibility after the DNS points the website to one of our servers. When a user visits whitelabel42.com, the request hits the reverse proxy, and it checks WhiteLabelConfiguration which contains an array of the list of our websites. Once it finds the matching white label information from WhiteLabelConfiguration, it passes the white label ID and other information downstream to the webserver and other downstream APIs and services with a white label header.

Managing Feature Configurations

Each white label has a set of features. The feature can be coupons, sign-up/log-in, or some regulatory requirements, such as the prices on the search page inclusive or exclusive of tax.

The above images are white labels. Notice the Japanese partner's website has a map of Japan's prefectures, which people can use to search for accommodations in the user-selected region. However, on Agoda, we do not have that map. Another example would be on the top navigation bar. On Agoda, we have language (shown as the flag of Japan) and currency (shown as $) settings which our Japanese partner disabled.

There are two types of features, boolean and configurable. The Japan prefecture map is an example of a boolean feature. We can either turn it on or off. On the other hand, we can configure the list of supported currencies for a white label. Which makes currencies a configurable feature. When there is no configuration for this type of feature, it means that it is disabled.

On the scale at which we are growing, Agoda has around 300 of these features. Each of these features may contain sub-configurations. This brings the total possible configurations to over 500 compositions and are growing by the day! Our challenge is how can we manage the configurations?

Let's explore some of the options we have tried.

Hardcoding

The most straightforward way to check if a feature is enabled or not is hardcoding. Something like:

However, this is neither scalable nor maintainable. Imagine having 100+, let alone 10+ white labels to manage. There will be 100+ if-else statements, enums everywhere, and another 100+ bugs as a result. We need to do better.

White Label Service: the Single Source of Truth

To have synchronized configurations across the system, we wanted to have a single source of truth for services from which to read. It should be easy to toggle and control the setting values.

As a result, we created a core service called White Label Service. This service serves the feature configurations for each white label. Most services in Agoda connect to and read the configurations from White Label Service.

Let's say a user visits a partner's website that has the same features as Agoda's, except sign-up/log-in. After the reverse proxy has resolved the URL and known that it is white label 42, it passes the information to the webserver. The web server reads the configuration from White Label Service and instructs the client-side that this white-label does not have log-in/sign-up. The client-side takes the parameters given by the webserver, realizing that it should hide all log-in/sign-up related features and renders the components accordingly.

Below is an example of our white label configuration:

which compiles to

This approach works well initially but is challenging to scale for more than ten partners. The more partners we have, the more configurations we have to take care of. We cannot rely on it to be the single source of every truth because it is hard to maintain, and some features are only helpful for the front-end. For example, the backend system ignores the links on the menu bar or the footer on the website. So, we came up with "client-side Behaviour Management".

Behaviour Management: the Client side's Source of Truth

Apart from the issues mentioned earlier, we found some challenges with making White Label Service the single source of truth. For example, it takes time to add and deploy a feature; it is difficult to have robust testing for a feature, etc.

We solved these challenges by introducing Behaviour Management which concerns client-side logic alone. With Behaviour Management, we define a behaviour, e.g., visibility of a button, the links in the footer, etc., in the client-side code itself.

A behaviour can be defined using a combination of conditions such as White Label ID, experiment ID, origin, etc. For example, we can create the HideFooterLinksBehaviour by checking if the White Label ID equals Agoda or is on the B side of an A/B experiment.

Below are examples of the behaviour:

Behaviour Management is not limited to just React, we can expand to other client sides as well. Our webserver, which is the client-side of the White Label Service and written in C#, can use Behaviour Management too.

In fact, Behaviour Management is a concept that can be adopted in any language as long as the necessary information such as White Label ID, origin, etc. can be resolved.

Some benefits of Behaviour Management are that we can use a code analyser and do unit testing; behaviour names are more related to the code itself, which is easier to identify, and we can create nested behaviours.

Two is Better than One

There are some situations that we want to take the configuration from the White Label Service to build a client-side specific behaviour. For example, we want to see if a White Label has Flights enabled, we can use the Flights configuration from the White Label Service to be a condition in a behaviour.

With the combination of the White Label Service, hosting the configurations for multiple services, and Behaviour Management, hosting the configurations for a single service, we have created a maintainable, extensible, and configurable system to build websites for our partners.

The combination can be visualized in the following diagram:

What did we learn from our approach?

To look back, we have come a long way and learnt a lot from the earlier easy-to-implement but hard-to-scale system to more sustainable and scalable architecture. We will test our solutions against new and unexpected requirements that adapt to support unique needs. We are confident that our solution is scalable and extensible when those changes are required.

Next Part: Development & Testing Environments

Now that white-label features and configurations are manageable, how about identifying solutions for each environment for various development stages? Buckle up to explore the last step before the deployment!

Read it now: Managing and scaling different white label development and testing environments.

Special thanks to Vlad Batushkov, Brinda Krishnan and Patthaphol Kulthawaiporn for their support and guidance.

Building and scaling different travel websites with one codebase was originally published in Agoda Engineering & Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

Working at Agoda as a Software Engineer

There are two ways to write error-free programs; only the third one works.
 — Alan J. Perlis

About a year ago, I made an important decision of my life. I moved from my previous start-up company to Agoda.

In this article, I’m going to share about my experience working here, how we work, what our daily routines look like. Even though my position is Full-stack Engineer, I believe this will be applicable for other tech positions as well.

How did I join Agoda?

I was working with my previous company, ViaBus, for some time. ViaBus was a start-up that creates a tracking app for the Thai public transport systems used by hundreds of thousands if not a million. It was great working there.

However, I have always wanted to try something new, working in a multicultural enterprise. It would be fun working with people from different backgrounds and learn different ways to work, wouldn’t it?

An opportunity approached me. There was a programming competition held by Agoda in late-2019. I instantly joined, just for fun. The competition saw around 5–7 questions. Some of them are algorithmic, some are problem-solving challenges. I finished at the 50th-ish place.

A few months later, there was a call from Agoda’s recruitment team. They gave me a list and asked me if I was interested in an opening position. I responded that I was interested in the client-side engineer, and full-stack engineer positions.

After a few more calls, I found myself in the Agoda office at the Offices at Central World, located in the heart of Bangkok. I was there to do interviews.

Interviews

For me, I had three rounds of interviews in a day. The first one was with two senior engineers. We discussed about my projects at the previous place. They asked me to solve a development scenario and try to optimise my solution.

The second one was with a data-team manager. He gave me a number of functions and asked me to use only these functions to find a solution to the challenge.

Finally, I did my last interview with a full-stack development manager. He asked my in-depth questions about JavaScript and asked me to solve some problems.

All interviews were conducted in English and there was a take-home development question that asked me to write a program in my language of choice.

I think this approach is a good approach since not only does it checks your computer science knowledge, but it was designed to ensure that you can actually write a program. Some people may find it stressful during the face-to-face interviews so they have not done very well but there is homework to help them prove themselves.

By the way, I asked a couple of colleagues, some said they had done only one round of interviews, the others said they had done up to five interviews.

First Day at Agoda

After the interview, about a week later, I got a call that landed me a position at Agoda. I delightedly accepted the offer and was asked to pick up equipment at the office.

I went to collect accessories at the offices a couple of weeks before my first day. I got a performant DELL laptop along with a laptop docking station, a set of welcome kit, and other necessary equipment. For other projects that require Mac, or you happen to need it, you will get a MacBook.

My first day at Agoda was in late-March. The infamous Coronavirus forced companies to embrace working from home. Agoda started working from home about a week before I joined. So, I began my first day at home.

Working from Home

Although I am an introvert and always try my best to avoid the presence of other human beings, working from home was not the best experience I have had, especially as a new joiner during the probation period.

Fortunately, I was placed in a team with a great, friendly, caring lead engineer. There was a coding scenario for new joiners to work with to get used to the technologies we are using. He helped and guided me through difficult parts and explained concepts I had never heard before. Props to him.

After the COVID-19 situation got better, we came back to our lovely office again. Now, we are working in the office.

The Teams

At Agoda, you will have great opportunities to rotate amongst exciting projects and teams.

My first team was the white-label team. We have been working with our Japanese partner, JTB, for a while. We are helping them build their new websites based on Agoda’s website and features. After a couple of quarters, I moved to a new team which is vastly different from the former.

The second team that I joined was YCS. Not only do we focus on hotel customers, but we also have a property management system for hotels to manage their bookings, properties. In this team, I got a great opportunity to design and implement a new feature which keeps track of external data of properties.

After the project has finished, I moved on to another team, SEO. Most of us search for hotels on search engines and book from one of the top results. The responsibility of this team is to make sure that we are at the top when a user search for a place to stay. Undoubtedly, SEO is one of the critical parts of Agoda. In this team, I was working on a project to migrate our indexation system from SQL to Hadoop, and create a new sitemap generator system.

All of these happen in just about a year! I have been rotated through teams which have enabled me to learn and acquire new knowledge and skills, and my journey will continue.

Technologies

On the client-side, we are using React + TypeScript. On the server-side, we are using C# (.NET Core) as the web server. These three pieces of technologies are the ones that all full-stack engineers have to touch.

If you are a a back-end developer, we are using a lot of cool technologies. The main tools are Scala, Docker, Hadoop, Spark. For databases, we are using Microsoft SQL, Couchbase.

How about tests? We write extensive tests for almost every project. We use Jest for testing our React code, NUnit/xUnit for C#, etc. We do all kind of tests, unit tests, integration tests, end-to-end tests, Selenium tests. We have a global site test system that catch production errors as well. Every time you encounter an error, we know and will fix it!

Apart from publicly available technologies, we build our own in-house tools as well. We have our excellent experiment system that does A/B testing and measure the success. Another example would be our BuildFlow system which handle our CI/CD process since we have over a half a hundred pull requests a day.

We have made some of our internal tools open-source which are available on our agoda-com GitHub.

Like other big enterprises, we still have some (ready for the scary words?) legacy code. Fortunately, it appears in few places and we are working to get rid of them. 😎

Daily Routine

We work using the Agile methodology. Most teams are using Scrum with 2-week sprint.

As a cool company, our start time is very flexible. On the paper, work starts at 9:00 but we can come whenever we want (just try to arrive before the stand-up meeting).

We begin our day with a stand-up meeting at around 10:30 and try to keep it short so we can spend our time on the thing that matters, coding.

Lunch is at around 12:00 but, again, you can have it whenever you want. Most people leave the office around 18:00–19:00. If you finish your work early, again, there is no need to stay late (or you can if you want to 😉).

How about meetings? We try to have as fewest meetings as possible and keep it short.

Working Cultures

As a diverse company, we have talented people from around the world. At Agoda, we commit to make the workplace inclusive for everyone no matter of one’s skin colour nor race.

We use English as the main language. Still, you should be able to speak Thai Dai Nid Noi (= a little bit) after a few months in.

Sometimes you may find it difficult when you disagree with your boss but, here at Agoda, you should be comfortable challenging your boss, your manager, your co-worker, or even the CEO (I have seen him got asked many challenging questions), as long as you’re challenging objectively, professionally, and respectfully. Why? Because everyone can be wrong, and anyone can be right. We should try to avoid going down the wrong track before it is too late.

Of course, there will be times when there is something in the way of getting your tasks done. If there is a blocker or anything that hinders your working velocity, you can always escalate to your or your team manager to solve the issue as timely as possible.

Speaking of managers, they are really easy to catch. You can always walk and talk to them to express any of your concerns, or just to have a chit-chat! You can also request a one-on-one meeting with your manager whenever you feel like one.

Agoda’s Tech Cultures

Another working culture at Agoda that really shapes the way the company has been is experiments. If you have an idea that might improve the website, why not experiment it? If the experiment results look promising, we will integrate as a feature. We have our own A-B testing experiment platform that we use to measure the success of a feature/implementation.

This is all possible with our data-driven approach. We trust data. Decisions are made based on the data that we have.

But how do we get the data? We measure. We measure (almost) everything, from the number of bookings increased with an experiment, to the clicks that a user makes. Thanks to this, we can deliver what users need.

Fun fact: we even measure the number of messages sent, meeting held, etc. during the WFH period and compared them with our time in the office.

Perks and Environments

On every floor, there is a pantry room for everyone to get some coffee or tea, grab some snacks, and have your lunch.

There is a coffee machine for you to have your essential cup before or during work. There are also cereals, bananas, and apples for you would you be hungry (but be quick! Bananas run out really fast!).

If you happen to be bored of the office’s snacks and drinks, you can always go down and pop into a café or restaurant in the shopping centre. There are hundreds of them to choose from! Don’t worry, there will always new shops to get you excited.

How about lunch? Many restaurants offer 10–20% exclusive discount when you show your Agoda badge!

What if you are tired of sitting? You can request a standing desk to improve your posture. If you experience back pains, there are massaging sessions on every Friday by people with visual impairments.

Also, there is a programme called Agoda Choice which allows you to choose between Fitness First’s subscription or 20,000 Baht to spend on well-being every year.

Activities

We have many kinds of activities here at Agoda. After work, we play board games, FIFA, Nintendo Switch, etc. If you are into physical sports, we have badminton, football, diving groups, etc. Sometimes we gather a group of people and do some CSR activities for communities and charities as well.

If you think working here has to be serious, I am sorry to tell you that we even have a Slack channel called #random. It is the place for great memes and everything else. On our internal Facebook Workplace, we have a group call ‘Cats Cats Cats’ which we share images of our cats at home or around our offices. It is one of the best groups.

If you want to expand your knowledge, we have Slack channels such as #dev-knowledge-share, #mastering-scala, etc. where you can learn and ask questions about development.

Every month, there often are internal tech talks where we share our knowledge, experiment results, or cool stuff. Some tech talks were really cool, for example, one explained how we are setting up our system so that it can handle a really huge number of data requested in a second, etc.

I’m Interested! What Should I Do?

If you’re interested and want to join this amazing company, you can visit https://careersatagoda.com and apply for your desired positions. Everyone from new grads to veterans are welcomed!

We hope to see you here!

A couple months ago, GitHub announced that they were rolling out Codespaces, but what is Codespaces?

Codespaces is an online IDE (Integrated Development Environment), a program used to write code. It's powered by Visual Studio Code (VS Code) which is a really popular IDE. If you're reading this, you must have heard of it. Why VS Code you may ask? Well, VS Code is Electron-based, was created by Microsoft and GitHub is a part of Microsoft. So that's that.

Let's move on to other topics.

Why?

The question might be why not?

It's on the cloud meaning that you don't have to install anything. If you can connect to the Internet, you can code anytime, anywhere. Setting Codespaces up is quite simple. I'll show later in the next section.

Also, it saves your storage spaces! If you're a web developer like me, you must have been suffering from the sheer size of the node_modules/ directory. In a project, it's fine. Many project combined? I'll let you do the maths.

Another great thing about Codespaces is that it's equipped. You can open any GitHub repository as you like (currently limited to non-organisation owned repositories). Making and committing changes can never be easier. Running Unix command lines? Installing some npm packages? Committing some changes? Boom! You can do it in the terminal easily. No installation needed.

How?

In order to create a codespace, head to your cool repository, (optional) create a branch, then click on the green button that says Code. A dropdown menu will be shown, select Open with Codespaces. Now, if you have created one before, you can choose the existing one. If you haven't or you want to create a new one, click the New codespace button.

You'll be greeted with a bright, light-themed VS Code. My eyes! Being good developers, the first thing we all do is changing to a dark theme (it's 2020 and dark themes aren't default, wtf?). I personally prefer Atom One Dark Theme (akamud.vscode-theme-onedark) I know that it's a matter of taste and I don't want to start a war on themes. I just want you to know that I respect all of your preferences and I won't judge but if you're using other themes (especially light themes), you're simply wrong.

That’s pretty much it. You can now enjoy the glory of Codespaces.

Let’s try it out!

I’m going to initiate a simple create-react-app and run to see if it works for this article and see if there’s any hussle.

I began by creating a repository to host the files.

As I mentioned, npm and node has been pre-installed. I can simply run npx create-react-app to install React.

And… we have it! A React app installed on Codespaces. (Excuse my tabs)

How about localhost?

When I tried creating a React app, my first question was how could I run the localhost?

Of course, GitHub developers thought about this. When clicking on the http://localhost:3000 link in the terminal, it opens a new tab forwarded to https://[random-string]-[port].apps.codespaces.githubusercontent.com and I can browse the newly-created React website easily.

By the way, you can also connect to your lovely locally installed VS Code using the Visual Studio Codespaces extension. It’s in preview and I haven’t tried it.

Costs

On the Codespaces page, it says

Pricing for Codespaces has not yet been finalized. Code-editing functionality in GitHub will always be free. We plan to offer simple pay-as-you-go pricing for Codespaces cloud environments. Codespaces is free during the limited beta.

So it looks like we’re going to have to pay for it but everything costs and nothing is free right? If the pricing is reasonable (hopefully it is), this could be a game changer.

What I LOVE about it

• Ease: It’s simple to get it run and you can code anywhere, anytime. No need to worry about storage spaces. (I’m thinking about using an iPad Pro 2020 (12.9") + Magic Keyboard as a laptop-replacement. If I go with this, I’ll write a review.)
• Continuity: I hadn’t committed the changes to git yet and closed the browser. After reopening the Codespace, the files are there as they should be.

Things that could be improved

• Bugs: With a few days of using Codespaces, I found a number of bugs. Some are fatal; some are dismissable. But hey, it’s a beta right?

• Shortcuts: When I pressed [Ctrl + W], I expected the current tab in Codespace to be closed, but instead, the browser tab was closed. It happens with [Ctrl + P] as well. This is really annoying since it happens on and off.
• Speed: It’s not that slow but it’s slow enough to feel and get annoyed. Being optimistic, it’s a good place to improve our patience.

All in all, I really love GitHub Codespaces. It’s convenient, cloud-based, and equipped. There are still some issues to be fixed before releasing to the public but they aren’t critical. This is something we should eye on.

Trying Out New GitHub’s Codespaces was originally published in thammarith on Medium, where people are continuing the conversation by highlighting and responding to this story.

<select v-model="somethingSomething">
  <option disabled selected>Select me</option>
  <option v-for="..." :value="..." :key="...">...</option>
</select>

However, I have this on many pages and it would be tedious to repeat myself.

So I went with creating a custom component and use that in every page I need. It looks like this

<template>
  <select @input="handleInput">
    <option v-for="item in collection" :key="item.id">...</option>
  </select>
</template>

<script>
export default {
  name: 'OptionSelectComponent',
  data() {
    return {
      collection: [...],
    }
  },
  methods: {
    handleInput(e) {
      this.$emit('input', e.target.value)
    }
  },
  mounted() {
    this.gettAllIconSizes();
  }
}
</script>

On the page you want to use, use

<OptionSelectComponentv-model="somethingSomething"></OptionSelectComponent>

and don’t forget to import

import OptionSelectComponent from '@/components/OptionSelectComponent.vue'

and export the component

export default {
  components: {
    OptionSelectComponent,
  },
  ...
}

Annnnd… Bob’s your uncle!

Explanation

Since it’s <select></select>, we have to check using @input which fires when an <option></option>is selected.

We handle the event using handleInput(e)with e (stands for event) as its argument. Then we emit the event along with e.target.value (how I got this? well, just console.log(e) and see which one is the one you you — it’s stupid and it works duh)

And that’s it. You can modify the code to get the result you want.

Reference

• Add `v-model` Support to Custom Vue.js Component by Samuel Oloruntoba retrieved from https://scotch.io/tutorials/add-v-model-support-to-custom-vuejs-component

ตู้ม! ผลลัพธ์
- 5คนเลือกข้าวแกงหน้าปากซอย
- 4คนเลือกเซเว่น
- 3 คนเลือกไม่กินเลย

สรุปว่าไปกินข้าวแกงหน้าปากซอยนะ

เห็นปัญหากับการโหวตแบบนี้ไหมครับ?

5 คนจาก 12 คน (41.66%) เป็นฝ่ายชนะ ทั้ง ๆ ที่อีก 7 คน (58.33%) เลือกอย่างอื่น อย่างนี้เรียกว่า ‘เสียงข้างมาก’ ได้ไหม?

การโหวตแบบนี้มีชื่อเรียกว่า First Past the Post (FPtP) ซึ่งหมายความว่า ใครที่ได้เสียงมากที่สุด ไปก็ชนะ ซึ่งเป็นการโหวตที่พวกเราใช้กันประจำ ไม่ว่าจะเรื่องเล็กเรื่องน้อย เราก็ใช้ระบบการโหวตแบบนี้

แต่ก็อย่างที่เห็นไปแล้วว่า การโหวตแบบนี้ไม่ได้ตอบโจทย์ทุกคน เพราะในตัวอย่างด้านบน คนเกินครึ่ง (7 คน) กลับแพ้ให้กับคน 5 คน

ถึงแล้วแล้วหรือยังที่เราจะมาใช้การโหวตแบบ ทางเลือก กัน?

การโหวตแบบทางเลือก

การโหวตแบบทางเลือกนั้นเกิดจากแนวคิดที่ให้ 1 คนโหวตได้มากกว่า 1 ครั้ง ซึ่งถ้ามองเป็นการเลือกตั้งจะสามารถยกตัวอย่างได้ดังนี้

มีผู้สมัครจาก 4 พรรคได้แก่
1. พรรค กขค.
2. พรรค ฅมฌ.
3. พรรค ฅษฌ.
4. พรรค ครม.

ถ้าหากเป็นการโหวตแบบทั่วไป เราก็คงให้กาแค่ 1 พรรคที่ชอบ

แต่การโหวตแบบทางเลือกนั้น จะให้เลือกว่า ชอบพรรคไหน ตามลำดับ

สมมติผลชอบพรรค กขค. > ครม. > ฅมฌ. > ฅษฌ. เวลาไปเลือก ก็ใส่ตัวเลข 1 – 4 ไปตามลำดับ ซึ่งก็จะเป็น (1) กขค. > (2) ครม. > (3) ฅมฌ. > (4) ฅษฌ. (ซึ่งในความเป็นจริงแล้ว ตัวเลข 1 – 3 ก็น่าจะเพียงพอแล้ว)

หลังจากนั้นเวลานับคะแนน ก็นับว่าใครที่คนใส่หมายเลข 1 ไปมากที่สุด ถ้าคนนั้นคะแนนยังไม่เกินครึ่ง ก็ให้ดูว่าคนที่ใส่หมายเลข 1 ให้พรรคที่ได้หมายเลข 1 น้อยที่สุด (พรรคท้ายตาราง) เลือกพรรคไหนเป็นพรรคที่ 2 แล้วนำคะแนนส่วนนั้นไปทดให้พรรคที่เลือกเป็นหมายเลข 2 ทำแบบนี้ไปเรื่อย ๆ จนกระทั่งได้พรรคที่ได้เกิน 50%

อาจจะฟังดูซับซ้อน และมันก็เป็นอย่างนั้นจริง ๆ ที่สำคัญ การเลือกแบบนี้ก็ยังมีปัญหาที่ว่าผลลัพธ์ที่ได้ก็ยังไม่ได้บอกสัดส่วนที่ชัดเจนของคนเลือก (ยังเกิดปัญหาแบบในตัวอย่างบนสุดได้) แต่ก็ยังดีกว่าการเลือกแบบที่เราใช้อยู่กันในปัจจุบัน (FPtP)

ในเมื่อยังมีปัญหา แล้วจะมาชวนให้ใช้แบบนี้ทำไม!?

ก็เพราะว่า มันเป็นทางเลือกที่ดีกว่า FPtP ครับ การเลือกแบบนี้ถึงจะไม่ได้แสดงถึงสัดส่วนของคนโหวตที่ชัดเจน แต่ก็จะได้ตัวเลือกที่คนส่วนมาก ยอมรับ

แต่ฟังดูงงจังเลยอะ ขอแบบง่าย ๆ ไม่ต้องมาไล่ลำดับได้ไหม?

ได้สิครับ!

เพียงแค่ครั้งต่อไปที่คุณจะทำการโหวต แทนที่จะขอให้ทุกคนเลือก ตัวเลือกที่ชอบมากที่สุด ก็ขอให้ทุกคนเลือก ตัวเลือกที่โอเค แทน

ซึ่งนั่นแปลว่า ทุกคนจะโหวตได้มากกว่า 1 ครั้ง

แล้วแบบนี้มันจะดีหรอ

ดีสิครับ ลองมาดูตัวอย่างแรกใหม่กัน แต่ครั้งนี้เราจะใช้ระบบโหวตแบบทางเลือกกัน

- a, b, c, d, e, f โอเคกับข้าวแกงหน้าปากซอย
- f, g, h, i, j โอเคกับเซเว่น
- a, b, c, g, j, k, l โอเคกับการไม่กินอะไรเลย

เห็นไหมครับ? คราวนี้จากที่ทุกคนต้องไปกินข้าวแกงหน้าปากซอย กลับกลายเป็นว่า ทุกคนโอเคกับการที่ไม่ต้องกินอะไรเลย ซึ่งทั้ง ๆ ที่เมื่อกี้มีคนเลือกแค่ 3 คน แต่ตอนนี้กลับมีคนโอเคด้วยถึง 7 คน ซึ่งก็เกินครึ่ง

ดังนั้น แบบนี้น่าจะดีกว่า

แล้วแบบไหนดีสุด

การโหวตแบบที่น่าจะดีที่สุด ก็คงเป็น Mixed-Member Proportional Representation (MMPR) ซึ่งให้เลือก 2 ครั้ง เหมือนการเลือกตั้งในไทยที่มีสส.แบบเขต (เพื่อการให้เสียงกับคนพื้นที่) และแบบบัญชีรายชื่อ (เพื่อให้เกิดสัดส่วนที่ถูกต้อง)

แต่จะกลายเป็นเรื่องที่ยากไป และไม่สะดวกกับการใช้ในชีวิตประจำวันสักเท่าไหร่

สำหรับคนที่สนใจ ก็สามารถเข้าไปดูได้ที่นี่ครับ https://www.youtube.com/watch?v=QT0I-sdoSXU (ภาษาอังกฤษ มีซับไตเติล)

สรุป

โหวตครั้งต่อไป แทนที่จะโหวตให้ตัวเลือกที่ชอบมากที่สุด ให้โหวตตัวเลือกที่รับได้แทน ตัวเลือกไหนที่คนรับได้มากที่สุด ก็จะชนะไป

รู้งี้แล้ว มาใช้การโหวตแบบทางเลือกกันดีกว่า เพราะนอกจากจะเป็นประชาธิปไตยแล้ว ทุกคนก็แฮปปี้ด้วย

เนื้อเรื่องนี้ได้แรงบันดาลใจจากวิดีโอของ CGP Grey (https://youtu.be/orybDrUj4vA)