// Solution 1
type LabelEntry = { label: string };
type ImageEntry = { image: string };
type Entry = LabelEntry | ImageEntry;

// Solution 2
type Entry = Record<'label' & 'image', string>;

An object type that I find myself creating very frequently is one that has one or all of several properties. For example, I can create an entry with a text label, one with an image, or one with both:

const textEntry = {
  label: 'Fluffy cloud',
};
const imgEntry = {
  image: 'cloud.jpg',
};
const bothEntry = {
  label: 'Fluffy cloud',
  image: 'cloud.jpg',
};

The problem​

Intuituively, I would declare the type for this kind of objects to be like this:

type Entry = {
  label?: string;
  image?: string;
};

There's a problem with this type. You can see the problem in the next listing with entry3:

const entry1: Entry = {
  label: 'Fluffy cloud',
};
const entry2: Entry = {
  image: 'cloud.jpg',
};
const entry3: Entry = {};
// We don't want to allow this to happen.

With this type definition, entry3 can be assigned an empty object. This is not the outcome that we want.

Solution 1​

One solution to the problem is to create two types and create an intersection type like so:

type LabelEntry = {
  label: string;
};

type ImageEntry = {
  image: string;
};

type Entry = LabelEntry | ImageEntry;

The entry3 variable above will show an error Type '{}' is not assignable to type 'Entry'. because it contains an empty object.

Instead it must have either one (or both) label or image as its property.

const entry1: Entry = {
  label: 'Fluffy cloud',
};
const entry2: Entry = {
  image: 'cloud.jpg',
};
const entry3: Entry = {
  label: 'Fluffy cloud',
  image: 'cloud.jpg',
};

Solution 2​

If coming up with names is not your strongest forte or you want to have fewer redundant lines of code, this might be your preferred solution:

type Entry = Record<'label' & 'image', string>;

Record is an utility type that helps to define the keys and values of an object type easily.

P.S. A mistake that I made before was using union (|) instead of intersection (&) for the key values (i.e. Record<'label' | 'image', string>). This would have made entry1 and entry2 invalid.

This post is a knowledgebase article on Prisma with PostgreSQL.

The typical model in a Prisma schema has an id field that auto-increments:

model User {
  id Int @id @default(autoincrement())
  name String
}

The following is working (most of the time) code that inserts a new entry:

prisma.user.create({
  data: { name: 'Some User' },
});

However, the following error may occur:

Unique constraint failed on the fields: (id)

This is baffling - if the field auto-increments, how can the unique constraint be violated?

Why?​

The answer (for PostgreSQL at least) is that this error typically happens if there is an entry created before that was not created using the auto-incremented ID. In other words, if there is an entry that was created where the ID was explicitly set, a conflict arises when Prisma tries to set its own auto-incremented ID.

Solution​

So, where possible, avoid setting the ID explicitly for tables which have the primary key field being an auto-incremented number field.

But what about...​

Alright, so we know what to avoid doing in the future. But is there a solution for tables that already have entries with manual IDs created?

As a matter of fact, there is!

SELECT setval(pg_get_serial_sequence('"User"', 'id'), coalesce(max(id)+1, 1), false) FROM "User";

Notice that the table name is encapsulated within a pair of single quotes and a pair of double quotes ('"User"')? This is because the name of the table begins with an uppercase character (U). This is a quirk of PostgreSQL. If the table name does not begin with an uppercase letter, the inner double quotes is not necessary (e.g. 'user').

See this discussion in Prisma's Github Discussions.

The source material came from this article by Thomasdevshare. His article describes a similar authentication scheme for Docusaurus with Firebase as the identity provider whereas this article describes the same approach using Google API directly.

The main concepts described in this article will be largely the same as that written by Thomas. The main differences:

• instead of depending on the Firebase package, the @react-oauth package is used, and
• a new section on designating allowed users to access the page.

(The example in this document is written in TypeScript but it should be easily applicable to JavaScript.)

Pre-requisites​

These are the things that you need to set up:

1. Google credential​

This step can be done at https://console.cloud.google.com/apis/credentials

Follow the Google instructions to configure your project and create a client ID for Web application.

For local development, add http://localhost and http://localhost:<port_number> to the Authorized JavaScript origins for @react-oauth to work. When deploying to production, specify the actual URL of your site.

Note the Client ID field for the OAuth 2.0 Client - this needs to be placed into the .env file (see below).

2. Add the @react-oauth/google dependency​

npm i @react-oauth/google

This dependency makes it easy to incorporate the Google SSO implicit-authorization flow.

3. Specify Google Client ID and allowed users​

Create a file .env in the root of the directory (same location as docusaurus.config.js) and add the following contents, replacing the text in arrow brackets with actual values:

GOOGLE_CLIENTID=<google client ID>

ALLOWED_USERS=<email addresses separated by commas>

GOOGLE_CLIENTID=1111111111111-djfh38dhf467as1hdgg3f2df334msd.apps.googleusercontent.com

ALLOWED_USERS=user1@example.com, user2@example.com, user3@example.com

The Google credentials obtained in Step 1 should replace <google client ID>.

<email addresses separated by commas> should be replaced with actual email addresses e.g. email1@example.com, email2@example.com

(The space after the comma will be trimmed by the plugin so it doesn't matter if the commas are followed by spaces.)

4. Configure docusaurus.config.js to read the environment variables​

Docusaurus is only able to read the environment variable during pre-processing. This means that the values in the .env file have to be "transferred" to the configuration file.

This is done by first adding the following line to docusaurus.config.js:

require('dotenv').config();

Then, somewhere in the file below, assign the process environment variables to properties under customFields:

const config = {
  title: 'Me3 Technical Documentation',
  customFields: {
    allowedUsers: process.env.ALLOWED_USERS,
    googleClientId: process.env.GOOGLE_CLIENTID,
  },
  // ...
};

Log-in Component​

Next create the log-in component. This component displays the Google sign-in button for the user to authenticate himself/herself.

Create a file src/components/login-google/index.tsx

import useDocusaurusContext from "@docusaurus/useDocusaurusContext";
import {
  CredentialResponse,
  GoogleLogin,
  GoogleOAuthProvider,
} from '@react-oauth/google';
import React from 'react';

export function LoginGoogle(props: {
  login: (string) => void,
  denied?: boolean,
}) {
  const {
    siteConfig: { customFields },
  } = useDocusaurusContext();

  const clientId = customFields.googleClientId as string;

  function handleError() {
    console.error('Failed to sign in with Google.');
  }

  function handleSuccess(creds: CredentialResponse) {
    const plaintext = decode(creds.credential);

    if (!plaintext) {
      return;
    }
    const payload = JSON.parse(plaintext);
    if (isAllowed(payload.email)) {
      props.login(payload.email);
    } else {
      props.login(null);
    }
  }

  // Checks if the supplied email address is allowed to see the page.
  function isAllowed(email: string): boolean {
    let allowedUsers = [];
    if (typeof customFields.allowedUsers === "string") {
      allowedUsers = customFields.allowedUsers.split(",").map((e) => e.trim());
    }
    if (allowedUsers.includes(email)) {
      return true;
    }
    return false;
  }

  return (
    <GoogleOAuthProvider clientId={clientId}>
      <div
        style={{
          display: 'flex',
          flexFlow: 'column nowrap',
          alignItems: 'center',
          margin: '5rem auto',
          textAlign: 'center',
        }}
      >
        <h2>Please sign in to your Google account to get access.</h2>
        {props.denied ? (
          <em>Not authorised</em>
        ) : (
          <GoogleLogin
            onSuccess={handleSuccess}
            onError={handleError}
          ></GoogleLogin>
        )}
      </div>
    </GoogleOAuthProvider>
  );
}

// Function to decode the JWT from Google to get the user's email address.
function decode(jwt: string): string {
  const parts = jwt.split('.');
  if (parts.length !== 3) {
    return '';
  }
  return window.atob(parts[1]);
}

Swizzle the Root Component​

Swizzling is a term describing the overridding of an existing component with a custom implementation of it.

The Root component is the component to swizzle as it covers all generated pages.

import React, { useState } from 'react';

import { LoginGoogle } from '@site/src/components/login-google';

export default function Root({ children }) {
  // `email` is used to determine if user is allowed.
  const [email, setEmail] = (useState < string) | (null > '');

  if (!email) {
    return <LoginGoogle login={setEmail} denied={email === null}></LoginGoogle>;
  }

  return <>{children}</>;
}

Conclusion​

One thing to note: the authentication information is only persisted in memory. What this means is that the authentiction is temporary (the correct term is ephemeral). The implication is that as soon as the user refreshes the page, the authenticated information (i.e. email address) is lost and the user gets "logged out".

This piece is a quick, non-technical introduction to domain names.

When I set out to write this article, I did not expect to write several drafts only to completely throw them away.

As I planned the outline of the article, I began to realise the depth and complexity of the topic. It was a challenge not to turn this into a technical write-up on DNS and nameservers in my attempt to elucidate the jargon and economics surrounding domain names.

So I decided to take on a consulting mindset for writing this article. I began with the question "What is the first thing that a small business owner would ask about his/her domain?"

The answer?

Cost​

The first thing that comes to mind for any small business owner is cost. It is only natural—even expected—that, as a (potential) business owner, you want to keep costs low as much as possible.

So let's start with that.

There are two types of costs you need to be concerned with: the acquisition cost and the renewal cost.

The acquisition cost is based on the domain name you want. For available domain names (names not yet claimed by anyone), the cost is very affordable - less than a hundred Sing dollars. You can purchase available domains on-the-spot easily with a credit card.

Then there are domain names that are held for sale. These domain names are kept for no other purpose than profit. This practice is known as cybersquatting.

I have not had to purchase a domain from cybersquatters before but the lowest price you are looking at is typically a four-figure sum. For comparison, a fresh .com domain costs around US$15. This huge price difference is why all my clients and friends have chosen to brainstorm for a fresh domain rather than to shelve out large sums of money to get an existing one. If cost savings is important to you, this is what I would recommend as well.

For a new domain, the renewal price is usually the same as what you paid for. That has changed now—there are tiered price domains that are sold at a higher price than what it costs to renew them.

So if there is a domain name that you very much want, but comes with a higher price tag, take a look again. The difference might be small enough (some might be a few hundred dollars) for you to stomach the one-time acquisition cost if the renewal cost is nominal. (See next section for examples.) Just chalk it off as a capital expenditure. 🤷🤷‍♂️

The renewal cost of a domain is usually based on its top-level domain (TLD). In simple terms, the TLD is the right most part of a domain name.

You should be familiar with .com - it is the most common TLD. Together with it, .net and .org are among the earliest TLDs introduced to the domain name system (DNS).

There are others, but I will only go through the types that are of relevance to this article in the next section on…

Types of Domain Names​

As mentioned in the previous section, .com, .net and .org are among the earliest domains introduced in the DNS. Coincidentally, they are also the cheapest to renew.

Acquiring them is not easy though. Being the earliest TLDs, they are also the most used. I think it is safe to say that any English word you can think of, the .com domain is probably taken.

If you can think of a new word or phrase then you will be able to get the .com easily without paying a premium.

To combat this shortage of names, ICANN has created other TLDs such as .app, .tech, .club, etc. For these TLDs though, some unclaimed domains already command a premium right out the gate. As mentioned previously these are tiered price domains. Below are a few examples of them:

My friends and customers target primarily the Singapore market. For them, either a .com or .sg/.com.sg TLD works fine. However, I do think that a .sg/.com.sg domain removes the ambiguity altogether for your target audience. In a way, it acts as a filter for traffic coming to your website, and for your audience, an implicit assurance that you are operating in Singapore.

Domains that end with a country specific suffix like .sg have country code top-level domains (ccTLDs). A ccTLD domain is likely more expensive than a generic TLD like .com, the reason being that the ccTLD has to be administered by a country-specific intermediary called a Network Information Centre. For Singapore, this entity is called SGNIC.

To have an idea of the kind of price difference, a typical .com domain costs around S$18 (US$13). A typical .sg/.com.sg costs around S$45.

Domains ending with .com.sg can only be registered by a Singaporean company entity. Domains ending with .sg may be registered by anyone residing in Singapore. To get a Singapore ccTLD, there is an additional verification of identity implemented by the VerifiedID@SG scheme. Singaporeans can access this scheme using their SingPass accounts.

Getting the Domain Name​

Most of you reading this would probably leave it to your appointed vendor to register the domain for you. This is totally fine, if your vendor is reliable.

As mentioned in the previous article, it is important that the registrant information is registered as your own.

The following scenario that I am going to describe is a worst-case scenario that I have not had to deal with yet.

Suppose your vendor registered his/her own information for all four pieces of information (billing, tech, admin, and registrant) for the domain (probably for no other reason than for convenience). If your vendor is a solopreneur/freelancer, all formal records would show that he/she is the sole registrant. In the event that he/she is not contactable for whatever reason, imagine how would you recover your domain?

Now, I am not saying that having your name lodged as the registrant will guarantee that you can recover your domain. But not having your name in any of the records will definitely not help you at all.

Therefore, you have to emphasize to your vendor/developer to make sure to enter your information for the registrant. Incidentally, if you are getting a .sg or .com.sg domain, you are required by the VerifiedID@SG scheme to verify your identity using your SingPass account. Note that this is in addition to the registrant info, so be sure that both are in order.

If you are inclined, it is perfectly fine for you to register the domain name by yourself. But be aware that at some point, you will need to map the DNS records for your domain to the server where your website resides. Alternatively, rather than doing it yourself, you may also pass your credentials to your vendor to make those changes for you.

What I recommend though (if you registered the domain name yourself) is to have your vendor change those settings in front of you. On the day when you "go live" (i.e. putting your website online), have the vendor come to your office. Sign in to your registrar's control panel, and let him/her change the DNS settings on the spot. This way, you need not reveal your password and worry about potential security issues.

I will not be describing the DNS settings in this article. It is too complex to describe in a reasonable length. You should leave this part to your vendor/developer to handle.

WWW or not?​

The last thing to mention is the www prefix. Unbeknownst to many, the www prefix, known as a subdomain, is an optional part of the domain name that is determined by your DNS settings.

From what I understand, this prefix also has an impact on your search rankings. Depending on configurations, it is possible to have your website served on both the www and naked domain (i.e. without the www). Google seems to frown upon this though - it considers them to be duplicate content. How it affects your website's ranking in the search results, I'm not exactly sure. All I know is that Google recommends not having the same content at different URLs. The naked domain and the www subdomain are considered different URLs.

My recommendation is that you ask your developer to redirect traffic from one to the other. It is usually a matter of preference whether to serve your website on the naked domain or the subdomain. My stance is that having a www subdomain makes it absolutely clear that what you are referring to is a website. This is all the more important if your chosen TLD is not a .com (e.g. www.example.app, www.example.tech, etc.)

Note that I am recommending the www prefix for your website, not your email address. It is absolutely unnecessary to have the prefix for your email address. In fact it is cumbersome to include the prefix for your email address. (Compare charles@school.com and charles@www.school.com)

This article has gone on long enough already. If the opportunity arises, I will discuss domain transfer and other topics in another article.

(Also posted on Medium and LinkedIn.)

I decided to write down all the advice on website building that I always give my friends and customers so that I don't ever miss anything out. This is the first of several articles.

I've been making webpages since the 90s. So I think I know a thing or two about building websites.

I really ought to since I've already built more than a handful of websites professionally and for my business owner friends.

Every time I do so, I find that I have to explain the same things to my clients and friends—the things to watch out for, the parts that make up the website, the available kinds of hosting options, etc.

The thing is, there are so many things to mention that each time I explain, I inevitably miss something out. So I decided to write it all down in the form of articles, listicles, or checklists that are easy to read and digest. My target readers are the average people and small business owners. I try to be as concise and non-technical as possible, so that they can read, understand, do it right, and get on with their lives.

To keep the length of this article manageable, I will discuss just the three fundamental things to look out for.

1. Make Sure Domain Ownership is Clear​

If there is only one thing I can share, it is this: make sure you own the domain!

"Why would I not own the domain? I paid for it!"

That's the typical response I get. The reason is that domain names are registered with ICANN through registrars. When a domain name is registered, there are 4 pieces of contact information that needs to be provided—registrant, admin, tech, and billing.

Most important among them is the registrant information—the entity/person that has registered for the domain.

So why would that be a problem? The issue is actually due to human behaviour. You see, people loathe to enter data into fields. The cognitive burden when entering fields for four contacts is even higher. As a result, many vendors are often tempted to enter one set of information (his/her own) and use the same for all four contacts (this is usually made possible by the user interface).

Most of the time, this is not a problem, but when it does become a problem, there is generally no recourse for the site owner. The problem typically manifests itself when the working relationship between the vendor and the site owner turns sour.

I have not had to deal with this yet, fortunately. But imagine if the vendor became hostile and denies the domain to you, the site owner, there would be no records of ownership as far as ICANN is concerned. If the vendor is not cooperative, it would take you a king's ransom and a long time in order to reclaim the domain.

This is why it is so, so important for you to make sure that the selected vendor is a reliable and trustworthy one. Otherwise, it might be better to just handle the domain portion personally.

I will be writing a piece on domain names separately to delve into more details.

2. Costs Are Not Necessarily Indicative of Quality​

Creating a website is not like buying a car where there are clear boundaries that links quality with the right price tag.

Two vendors (developers) can quote the same price for a website but deliver wildly different results.

In my next piece on website fundamentals, I discuss the dirty little secrets of the industry (among other reasons) that explain why there is now such a large variation of quality.

So if price is not the answer, then what is?

There are generally two ways to make sure you hire the right developer.

One, check out the developer's previous work. For most of you reading this, the only criterion by which the work can be judged is through the aesthetics. That is well and good, but may not be sufficient, as I'll explain in another article.

Two, have the developer create the mock-up (also sometimes referred to as the prototype) of the website before starting actual programming work. This way you can have an idea of what the final product will look like much more quickly (and cheaply) than waiting for the site to be fully developed. This is the way it is because it takes a lot more work and time to create the actual website than to illustrate what the final design will look like.

To make it fair for both parties, I always recommend creating the mock-up first. Let's be clear, the mock-up isn't some sketch or hand-drawn representation of the site. Rather, it is an almost exact replica of the website. There are tools now that do not even cost money that the vendor can use to present the final look-and-feel without writing a single line of code.

I also recommend that you pay a fair sum of money for this prototype. While no code is written, it still takes time, effort and creative brain juice to think of and create the design. There is no right figure as the price of a website may differ greatly. Generally though, some 10% to 25% may be a ballpark figure to pay for this mock-up. It is a good way to hedge the risk and still be fair to both you and the vendor.

3. Check the Email Service Provider​

From my experience, when a business owner wants to create his or her own website, that usually means there is no decent email service as well.

By "decent" I mean an email address ending in the same domain as your website. That means no @singnet.com.sg, @gmail.com, or @outlook.com addresses.

This is another topic that warrants another article. For now just be aware that there are many email server options that may be close in price but vary greatly in terms of features and functions.

I think that Gmail has set the gold standard for email service. To me, an inbox capacity of less than a gigabyte is not considered usable given the propensity for people to send large attachments nowadays.

Yet, there are still traditional providers that provide (understandably small capacity) email accounts along with web hosting as a package on the cheap. While that might sound nice, especially for the start where you think "I can just change when my business grows", the reality is typically different.

Email is a critical business function in the work environment. When you start outgrowing your meagre inbox capacity, you'll start to experience all the inefficiencies and potential lost businesses due to a full inbox.

If you then want to switch to a bigger inbox, and you wish to move the contents from the old inbox to the new one, there is then this email migration cost that you will have to factor in. This migration cost is significantly higher than the subscription price of your email service. Unless… you are alright with putting up with the inconvenience of switching between your old inbox and the new one (and potential confusion that comes with it).

Bear in mind that this does not affect just yourself but the other coworkers in your company that have an inbox. So any inefficiency/lost productivity is magnified.

In summary, if you want to avoid this kind of headaches and potential lost productivity, be sure to get your email hosting solution right at the start.

(If you want to have the Gmail equivalent experience for your inbox, use G Suite! If you decide to go with that, hit me up! I've got promotion codes for you that give you 20% off the first year subscription per user. Also, I get a commission 😉)

So that's it. These are the three things that I would advise anyone thinking of commissioning a website to establish a web presence. Reach me on Twitter (@chuacheehow) if you have any questions.

(Also posted on Medium and LinkedIn.)

My thanks go to Abdul Rahman for helping with proofreading.

Two months ago I left the company which I co-founded 13 years back. Here are some of my takeaways after 13 years as its CTO.

But first, an introduction.

Back story​

We are a company focused on education technologies that improve the pedagogical aspects of learning in schools.

Throughout our 13 years of operation, we've taken on work and projects of different scopes. We started with software training for adults. Back then Photoshop and its ilk from Adobe, and Dreamweaver and the Macromedia suite of applications were the must-knows for image manipulation and Web development.

Business was slow. A year or two after we started, we reached an inflection point. We had to decide to wind up or to pivot to a different business scope. Being the young and full-spirited youngsters we were, we wanted to give entrepreneurship another shot before throwing in the towel. With a stroke of luck, through the relationship that one of the founders had with people from Novell, we got on board a programme to supply training services to public schools.

Back then, there was a strong emphasis on graphical programs and interactive multimedia as a result of the Ministry of Education (MOE) IT Master Plan. With the fortuitous early investment (of time) I made into learning the Adobe and Macromedia suite of programs (think Photoshop, Flash, Dreamweaver and the likes), I was able to conduct the courses that we pitched to the schools.

Thanks to our partnership with Novell, we were able to gain some traction with school trainings. As Novell had acquired SUSE Linux not too long back, we also had the privilege of introducing Linux to schools. It was also then that I really sunk my teeth into Linux. (Since then, I've switched to using Linux on the desktop exclusively. I'm very thankful for that chance to really learn Linux well.)

The margins from training were already slim back then. Competition was intense, coming from one-person shops to existing incumbents. We thus had to be opportunistic, grabbing all kinds of deals that came our way. Along the way, through Novell and other channels, we also got a few deals that involved server deployment - completely unrelated to education.

As the sole technical founder, I had to equip myself with knowledge of Linux server deployment to perform the actual deployment while also conducting trainings in schools.

When it comes to the choice of projects, we were really not discerning, all in the name of survival. In 2006 (I think), we even clinched the deal for technical support for the Nokia phones distributed to the attendees of the International Monetary Fund (IMF) conference in Singapore.

Google​

Sometime between 2006 and 2008, we had our first contact with Google. At that time, they were located at Shenton Way where they took up an entire floor (or was it two?) in AXA Tower.

It was also then when we were introduced to what is now known as G Suite. We were early to the party. Being education focused, we were the first to introduce Google Apps, as it was then called, to schools.

We also became a reseller, selling Google Apps to commercial entities (the education edition is free of charge to educational institutes).

That went on for a while until we also became a Chrome Device Management license reseller with our own brand of Chromebooks.

Applications​

Along the journey, we also created a plethora of applications:

• Chromeclass (software to manage student Chromebooks),
• Woma (workload management tool for Google Classroom),
• WebNap (cyber safety testing tool),
• Jotterlab (this name was used for different projects as we groomed and killed a few initiatives along the way),
• VLS (stands for Virtual Lab for Science),
• Trusted Network Extension (an IP tracking tool),
• GFlip (video repository for flipped learning),
• Ductbooks (a book delivery and management system),
• Edurious (a component of an learning management platform for low bandwidth environments), and
• Locus (a shared access terminal for Chromebooks with more controls than a Chromebook in Public Terminal mode).

Among these, a third of them were just proof-of-concept. One third of these is still being used by customers. The remaining are in the trash.

Unified vision​

So that was the story for 13 years in a nutshell. When we started, there were four shareholders. When I left, there were only two key decision makers, including myself.

Probably as a result of having only two decision makers, some of my realisations were more palpable than others.

In order for a company to move as a whole, there must be a clear direction to move towards. In corporate speak, this is the company vision and mission.

If there is no consensus as to what the company vision and mission are, then the baseline mission is profit maximisation. The organization then behaves like an indiscriminate eater, gobbling up every piece of morsel that comes its way, regardless if it's toxic or nutritious.

In some cases, a one-off project with seemingly low returns, if any at all, may be necessary as part of an overarching strategy, to augment the company's position in the market. These projects are necessary evils, medicine that the company must take to further its business interests.

In other cases, such one-off projects with seemingly high (potential) returns may feel like the sweet flesh of low lying fruits but they draw the company's resources away from its core focus. In the best case, they are profitable distractions. In the worst case(s), they are loss-making adventures that hold the company back.

Gauging product market fit​

Before committing to making a product, make sure that a good part of the market wants it.

We made the critical mistake of “surveying a market of one”. We didn't do enough market research to identify the market demand for the Web app we were planning to make.

Just because we hear the need from one or two potential customers, it does not mean there is a market demand for a solution. This statement sounds so obvious that it is almost redundant to state it. The problem is that we often fall to the trap of hearing only what we want to hear. When the person at the other end is in 100% consensus with you, it can feel like the whole world is in agreement.

One trick to identify this kind of conversation is when the person makes sweeping statements like “Oh, everyone will need this solution.” It is not so much the accuracy or correctness of the statement (because who knows for sure?) that is the problem but rather that such statements lull the subconscious into thinking that they are facts rather than opinions or guesses.

Ease of use trumps value proposition​

The value proposition provided by an application must be a magnitude greater than the effort to achieve it.

I learnt this lesson from the same failed project that showed the importance of market demand.

The software was to help students become better essay writers by making incremental improvements to their essays through a methodology called “process writing”. With this methodology, students write several versions of an essay. Their peers and teachers can the review the essay and make comments on areas that need improving.

This all sounds good.

The problem is that we did not realise the amount of work required in this process, for both the students and teachers. From the perspective of students, writing just one essay is already a lot of work. To have them write the same essay more than once, in addition to their other assignments, is a tall order. Ditto for the teachers, whose workload is already too much. There is little to no incentive to use such an application.

Despite the premise of the program, it was simply too much additional work for the users. The project was doomed to fail at conception.

What it takes to make good software​

Being able to rapidly prototype an application to validate an idea does not mean it is trivial to write good software.

Very often, in the quest for rapid development, developers have to take shortcuts. Such shortcuts may meet the project's current and immediate goals but are typically detrimental to its future development. Such shortcuts are known as technical debt.

Like financial debt, the more you take on, the deeper you sink. Without understanding this, it is so easy to fall into the trap of thinking that a software project is done once all the checkboxes are ticked.

Feedback loop with early customers has to be proactive and regular. A software product is almost always never done. There are always features to add, and bugs to fix.

The people who put money with you before you have any traction is trusting you with their money. There is a moral imperative to reciprocate that trust by making the product/service the best that it can be. If, however, you need to keep getting different projects then either a) the model of creating your own software is not tenable, or b) the project is not something that the market needs i.e. the project should not exist, and should be trimmed to make space for (allocate resources to) other projects that might have a better chance of succeeding in the market.

In conclusion​

The company is now, and has been for a few years, stable and growing the Chrome business. We would not have imagined the hardware business making up the main chunk of the revenue, and yet, the company now stands as the Singapore's leading company for G Suite and Chrome technology in the education sector. With any luck, the company may still soar to greater heights in the right direction and focus. I wish for only the best to the company and my former colleagues.

(Also posted on Medium and LinkedIn.)

In the previous article, I wrote about my attempt at improving my pitches. I left off from that piece with the promise of a formula that can improve the quality of your slide decks immediately.

The answer: storytelling.

The problem with this statement is it seems too simple, even patronizing, an answer.

From another perspective, it could be that because the answer is so simple, it is easy to dismiss.

But if you can take a moment to digest this answer, you will begin to realise that it makes sense. Notice that in any TV series, every episode tries to end with a cliffhanger. Producers do that because they know that it makes the audience look forward to watching the next episode to find out what happens next, that they want to “fill in the gap” in the whole story.

Storytelling is a process from the start to the end. Anything missing in this process is a gap. No one likes gaps. Everyone wants closure. That’s why it is more painful to lose a loved one suddenly because we lose the chance to say our last words - closure.

Every Hollywood movie nowadays have equally stunning visual effects but what makes one movie A-grade and another subpar is really the quality of the story, an element that is not as much observed as it is felt.

“If storytelling is the answer, then what is the formula?” I can already imagine this question surfacing in your mind as you read this.

The answer can be found from this Medium piece by Andy Raskin.

I replicate below the points which he made in that article:

1. Name the enemy
2. Answer “Why now?”
3. Show the promised land before explaining how you’ll get there
4. Identify obstacles—then explain how you’ll overcome them
5. Present evidence that you’re not just blowing hot air

If you are really interested in brushing up your presentations, go read that piece. It’s only a 5-minute read.

I also like to share this video series on YouTube featuring Ira Glass from This American Life where he talks about creating compelling storylines using anecdotes and a series of actions and questions.

I’m certainly no presentation expert (far from it), but by just applying what I’ve learnt from the Raskin article and Glass videos, I do think that my works have improved from what they were before.

I hope they will do the same for you. Share your thoughts with me in the comments below or on Twitter @chuacheehow

(Also posted on Medium and LinkedIn)

I’m always looking for ways to improve my presentations. Oftentimes, I only get one chance to get my point across and I want to make every such opportunity count.

I had once thought that the key to well done presentations is a slick, animated slideshow with concise key points. Now I know better. What you use as the visual material is secondary to what you are saying and how you say it.

I would attribute the “how you say it” to the command and fluency of the language that you are presenting in. This has to do with the richness of your vocabulary and the structure of the sentences that you articulate during the presentation. Your language skills, like any other skills, can only be improved through repeated practice. So there’s that.

“What you say” though are the contents of your presentation. Some might argue that how you say it is more important then what you say. That argument, I think, is probably only true for the very few speakers who seem to naturally exude such charisma that can charm the masses. Needless to say, that is certainly not an attribute that the large majority of us can emulate.

Contents, however, are highly malleable. They are the one thing in the presentation that you can change with ease. What is not as easy is to know what to change it to.

We all want an easy-to-apply formula that we can use on our presentation decks right now while we polish up our language skills and vocabulary gradually. But does such a formula exist? If so, it sounds too good to be true, isn’t it?

What if there is such a thing? And that it is the same formula that differentiates an A-grade movie from a B-grade one.

If you feel that all the presentations that you have ever done in your life are, how should I say, lacklustre, then you can probably see a great improvement in your slide decks simply by applying this formula. I know that it works for me.

Like any good show, I am going to leave this post on a cliff-hanger and come back with the second and final part of this article next time.

(Also posted on Medium and LinkedIn)

Several months back I was addicted to Twitter. Any time I can pull out my phone, I would be checking my Twitter feed.

It's a time waster. Prolific YouTuber Dr Derek Muller describes it as a part of the distraction economy.

I had even gone to the extent of checking for more updates when I had finished everything in my feed. What was the use of that? Is there anything to gain from all that time spent reading little messages from strangers?

Given that each message is at most 140 characters, surely Twitter's only value is for newsy stuff right? Well, that's mostly true but every now and then, you can find a gem of wisdom among the stream of ramblings.

And found one I did. I don't remember the exact wording but the gist revolves around these two sentences:

"Why is this job important?"

"What you will learn in this job."

This was posted by someone who was in the position of hiring (programmers I think). He found that by including these two points in a job advertisement, it helped to attract more quality candidates than not.

After parsing through the sentences, I can see why. The first point "What is this job important?" probably does not make sense to a lot of people why it would help. The second point "What you will learn in this job." is probably more obvious. Clearly it speaks to people who want to learn more. Beyond that though, if we delve a little deeper into the characteristics of the people who place emphasis on it, we can easily see that these are people who want and desire to acquire new knowledge.

Naturally, if I were to infer another characteristic that makes such a person perpetually curious, it would be interest, or for some, passion. Only when you have interest/passion in a job, would you be always keen to learn more. And a person who is interested/passionate can be counted on to complete the tasks satisfactorily, not necessarily to the supervisor but simply to herself.

What about the first point? What can we infer from it?

A disassociated worker likely doesn't give a damn about why the job is important. I can think of two traits in an individual who does give a damn.

One is the ability to think at a higher level, "see the big picture", and understand and appreciate the role that she is playing in the organization for the job that she is doing.

The other is an innate desire for self actualization. For some people, the knowledge that one has a significant role to play in the company provides the extra motivation to work hard. I think that's probably the reason why some people stay behind after office hours to complete the task at hand whereas others adopt a "couldn't care less" attitude in the office.

Simply adding these two points in the job advertisement will not magically filter out the dispassionate candidates, but you can leverage these two points during the interview to "suss" out these hidden personality traits in the candidates.

If you are in a position of hiring, try this out the next time a position is available and see if it works for you.

Given the setup below, I would have been a little hesitant as to what the right answer is.

function Alpha() {
    this.name = 'A';
}

Alpha.prototype.say = function () {
    return this.name;
}

function Beta() {
    this.name = 'B';
}

Beta.prototype.say = function () {
    return this.name;
}

var name = 'G';

function say() {
    return this.name;
}

function echo(action) {
    console.log(action());
}

a = new Alpha();
b = new Beta();

a.say(); // returns A
b.say(); // returns B
say(); // returns G

Nothing fancy up to this point. But the next 2 lines will make me think a bit.

echo(a.say);
// Output: 'G'
echo(a.say.bind(a))
// Output: 'A'

This next part is the kicker.

function Delta() {
    this.name = 'D';
    this.say = this.say.bind(this);
}

Delta.prototype.say = function () {
    return this.name;
}

d = new Delta();

d.say();
echo(d.say);

What do you think the output is?

ANSWER​

Both lines output "D".

This example shows that there is a case for early binding even on prototype methods.

At that point in time, the G4 was considered slightly below par compared to the Note 5, in terms of price and branding. I had aimed for a V10 but there was completely no news about it being available in Singapore.

Despite being a flagship phone for Samsung, there were plenty of reasons for not choosing the Note 5 then - the stylus problem, the non-removable battery and the lack of external storage. I had no regrets not selecting the Note 5.

Notwithstanding all the shortcomings, I had a more pragmatic reason for choosing the G4 over the Note 5 though - price. To me, it was that I did not think that the Note 5 was worth the extra money over the G4; all the features that the phone touted (and the Samsung branding) were not worth the premium over the G4.

Now, my stance is more opinionated - I think the support for LG is simply better than the Samsung. In the time between my wife getting her Note 5 to her first OS upgrade from Android 5.1 to Android 6, I had already gotten three updates. My G4 was revved up to Android M months before her Note 5 was upgraded. My G4 also got another update recently, though I'm not sure what the upgrade was - my assumption is that it is for some security patches.

Regardless of the reason for the latest update, the fact that LG has provided more frequent updates than Samsung has (for its flagship phone no less) is enough reason for me to not choose Samsung phones again.

P.S. I had begun writing this article before the Note 7 battery problems surfaced so the battery problem wasn't the genesis for my opinion.

(2023 February note: Disqus was not enabled after the switch to Docusaurus)

The easiest way that I thought of was to create a DIFF file and pass the file to the other members so that they could patch the project prior to deployment to production servers.

The most straightforward way to create a DIFF file is to use git diff. But the question was how can the DIFF file be used to "patch" the project?

Thanks to the (blog post from Thomas Amsler)[http://tamsler.blogspot.sg/2009/02/patching-with-git-diff.html], this is easily achieved.

First, create the patch file like so:

git diff --no-prefix > patchfile

This file can then be used as a patch like so:

patch -p0 < patchfile

If the patch was created without --no-prefix, the patch level should be 1 instead:

git diff > patchfile patch -p1 < patchfile

However, loading the SWF file in Chrome on Linux does not work; loading the file causes Chrome to prompt the user to download it - definitely not the reaction I was hoping from the browser. Trying to solve this problem lead to learn a new thing about MIME types in Linux.

From superuser.com, I learnt that file associations are placed in the file

/usr/share/mime/packages/freedesktop.org.xml

and that the default MIME type for swf is

<mime-type type="application/vnd.adobe.flash.movie">

To make the SWF file play in the browser, change the MIME type to

<mime-type type="application/x-shockwave-flash">

and then update the association by running

update-mime-database /usr/share/mime

Some time back when researching for Backbone JS stuff (I can't remember for what now), I encountered this post Lessons learned while working with Backbone.js.

This post was written a few years back, but I was still able to glean some gems from it. Specifically, the section "Simplified Object Copying" was something that could be applied on plain vanilla JavaScript.

The other section "Changing in referenced object does not trigger events" was something that I had already discovered on my own. The author's solution was to create a copy of the object to assign to the model. In my work, I had chosen to manually trigger the change event. In terms of correctness, I guess creating a copy and re-assigning to the model would be more so since that would trigger both the general change event as well as the change:name event.

While I like to think that this could be one of my last posts on BackboneJS, with Angular JS being the new hotness, I'm facing a bit of inertia in switching to Angular. No doubt Angular is newer (I think) and coming from Google, isn't likely to disappear in oblivion anytime soon, the rapid change from Angular 1 to 2 is a bit disconcerting. Being a solo developer, I don't have the luxury of time to always keep chasing after the new kid on the block.

Even though the quick start guide says that npm is only a recommended component, my guess is that development without npm is going to be painful. I've never had the chance to truly understand the ins-and-outs of npm, so I won't be able to work around it effectively. I always have a resistance to using development environments that require other components before any effective coding can start. This means that every time I change a machine, I always have to run through a (mentally) tedious setup process. It also means that if I have a different development (one at home and one at the office), I need to keep the development environments on both machines the same in order to do my work effectively.

So, yah, I guess I'll be sticking with BackboneJS for some time in the future.

Backbone events are a powerful way to write responsive user interfaces with fewer lines of codes. This article attempts to give a detailed breakdown of the events and the parameters available for the callback functions.

The results in this article are applicable for version 1.2.3 of Backbone.js

The test is performed by instantiating instances of ExperimentModel extended from Backbone.Model and ExperimentCollection extended from Backbone.Collection.

The model is first added to the collection to test "add" on the collection and then a properrty is set on the model.

var expModelA = new ExperimentModel({ id: 'a' });
var expCollA = new ExperimentCollection();

Add

expCollA.on('add', function (model, collection, obj) {
    ...
});
expModelA.on('add', function (model, collection, obj) {
    ...
});
expCollA.add(expModelA);

In both of the callback functions 3 parameters are passed:

1. model

The model being added to the collection.

2. collection

The collection after the model is added.

3. operation object

A map containing the following keys (and values):

• merge (false)
• add (true)
• remove (false)

Remove

expModelA.on('remove', function (model, collection, obj) {
    ...
});
expCollA.on('remove', function (model, collection, obj) {
    ...
});
expCollA.remove(expModelA);

In both of the callback functions 3 parameters are passed:

1. model

The model being added to the collection.

2. collection

The collection after the model is added.

3. operation object

A map containing the following key (and value):

• index (the position in the collection of the model that was removed).

Update

expCollA.on('update', function (collection, obj) {
    ...
});
expCollA.add(expModelA);
expCollA.remove(expModelA);

The update event is only called on the collection when a model is added to or removed from the collection. Its callback function receives two parameters:

1. collection

The collection after the model is added.

2. operation object

A map that contains different keys and values depending on the type of operation (add or remove). See Add and Remove for details.

Sort

expCollA.on('sort', function (collection, obj) {
    ...
});

This event can be triggered when a model is added to/removed from the collection. It can also be triggered by a call to sort()

collection

The collection after the model is added.

operation object

A map containing the following keys:

• merge (boolean)
• add (boolean)
• remove (boolean)

The values in this map indicate the operation that occurred that triggered the event. If this event was triggered by invocation of sort, this map will be empty.

Change

expModelA.on('change', function (model) {
    ...
});
expCollA.on('change', function (model) {
    ...
});

This event is triggered on both the model that was changed, and the collection that the model is in.

model

The model that was changed.

Reset

expCollA.on('reset', function (collection, obj) {
    ...
});
expCollA.reset();

The reset event is invoked by the reset() method. This method accepts an optional parameter that is the list of models used to replace the collection. The callback function receives 2 parameters:

collection

The collection after the reset operation is completed.

options

This object has the previousModels property that holds the models that were replaced by the reset() operation.

(2023 February note: The script below was supposed to update the tables in this page. But since the change to Docusaurus, the needed scripts are no longer available on the page so the code does not work anymore. They are left here for posterity.)

<script src="/js/lib/jquery.min.js"></script>

<script src="/js/lib/underscore.min.js"></script>

<script src="/js/lib/backbone.min.js"></script>

$(document).ready(function () {
    var tick = '&#x2713';
    var ExperimentModel = Backbone.Model.extend({
        defaults: {
            name: null
        },
        validate: function (attrs) {
            if (!attrs.name) {
                return 'name is required';
            }
        }
    });
    var ExperimentCollection = Backbone.Collection.extend({
        model: ExperimentModel
    });

    console.info('Instantiating ExperimentModel A', expModelA);
    var expModelA = new ExperimentModel({
        id: 'a',
        name: 'Alpha'
    });
    console.info('Instantiating ExperimentCollection A', expCollA);
    var expCollA = new ExperimentCollection();
    expCollA.comparator = 'name';

    expModelA.on('change', function (m) {
        console.log('Model: change', m.toJSON(), arguments);
        $('.change-model').html(tick);
    });
    expModelA.on('sort', function () {
        console.log('Model: sort', arguments);
    });
    expModelA.on('reset', function () {
        console.log('Model: reset', arguments);
    });
    expModelA.on('update', function () {
        console.log('Model: update', arguments);
        $('.update-model').html(tick);
    });
    expModelA.on('add', function (m, c, o) {
        console.log('Model: add', m.toJSON(), c.length, o);
        $('.add-model').html(tick);
    });
    expModelA.on('remove', function (m, c, o) {
        console.log('Model: remove', m.toJSON(), c.length, o);
        $('.remove-model').html(tick);
    });

    expCollA.on('change', function (m) {
        console.log('Collection: change', m.toJSON(), arguments);
        $('.change-collection').html(tick);
    });
    expCollA.on('sort', function (c, o) {
        console.log('Collection: sort', c.length, o);
        $('.sort-collection').html(tick);
    });
    expCollA.on('reset', function (c, o) {
        console.log('Collection: reset', c.length, o);
        $('.reset-collection').html(tick);
    });
    expCollA.on('update', function (c, o) {
        console.log('Collection: update', c.length, o);
        $('.update-collection').html(tick);
        if (o.add) { console.log('ADD'); } else { console.log('REMOVE'); }
    });
    expCollA.on('add', function (m, c, o) {
        console.log('Collection: add', m.toJSON(), c.length, o);
        $('.add-collection').html(tick);
    });
    expCollA.on('remove', function (m, c, o) {
        console.log('Collection: remove', m.toJSON(), c.length, o);
        $('.remove-collection').html(tick);
    });

    //Steps
    console.info('Adding model A to collection A');
    expCollA.add(expModelA);
    console.info('Setting name on model A');
    expModelA.set('name', 'Experiment A');

    console.info('Removing model A from collection A');
    expCollA.remove(expModelA);
    console.info('Unsetting name on model A');
    expModelA.unset('name');

    console.log('Adding model A back to collection A');
    expCollA.add(expModelA);
    console.info('Changing name of model A');
    expModelA.set('name', 'Aloha');
    console.info('Resetting collection A');
    expCollA.reset([
        new ExperimentModel({ id: 'd', name: 'Delta' }),
        new ExperimentModel({ id: 'c', name: 'Charlie' }),
        new ExperimentModel({ id: 'b', name: 'Bravo' })
    ]);
    console.warn('Final length:', expCollA.length);
});

Memory-managed programming languages like Java and PHP have made memory pointers much less important. For better or worse, programming has become a much less daunting endeavour now.

As a regular JavaScript writer, I have become used to the affordances that the myriad array of frameworks have provided in terms of convenience and abstraction from the nitty-gritty parts of the language. Instead of writing "straight-up" JavaScript, I just call a bunch of functions here and there and get the job done in half the time. So this post is an exercise to recap the basics of JavaScript.

Just in case you, dear reader, are new to JavaScript, it is a loosely-typed language. This means that a variable can hold any type of data.

The types of data in JavaScript are:

• string
• number (integer, float)
• boolean
• function
• object/array
• null
• undefined

The first three (string, number and boolean) are primitive types of the JavaScript language. You never have problems with straight-up variable assignment with them.

var a = 'string';
var b = 1;
var c = b;

b = a;
console.log(a); //'string'
console.log(b); //'string' because of b = a
console.log(c); //retains 1

So a variable can be assigned one type (integer) and re-assigned to another (string) with no confusion.

In a straight-up assignment, you expect b to be updated with the value of a.

What is not clear to beginners is since c is assigned the value of b, does changing the value of b affect the value of c?

The answer is no because when an assignment takes place in JavaScript, the contents are copied over to the assigned variable.

In a language with pointer arithmetic (such as C), things will be different, and a little complicated, when pointers come into the picture.

Things become interesting when you start working with contents of arrays.

Let's see what happens if the value of the array is assigned to another variable.

var a = [1, 2];
var b = a;
var c = a[0];
b[0] = 3;
console.log(a); //shows [3, 2]
console.log(b); //shows [3, 2]
console.log(c); //shows 1, not 3

If you are expecting c to show the value of 3, you are not alone.

What happens here is that when the assignment of c happened, a copy of the value in b[0] was made and assigned to c.

When b was assigned a, a copy of the location of the array in memory was made and assigned to b. Thus, when b and a are referenced, they both point to the same location in memory i.e. the same array.

In summary, the difference between the examples lies in the fact that with array values, we are essentially working with memory locations as compared to actual values.

I'm deferring the use of the terms "pass-by-reference" and "pass-by-value" here because, like politics, everyone has his/her own opinions, and everyone disagrees with everyone else's views. Things become even more complicated when you are talking about a language that does not have direct memory arithmetic.

Contrast this to infrastructure-as-a-service (IaaS) where I decide on the number of servers to spin up for my application.

The benefit of a PaaS offering is an abstraction of the underlying server stuff (and all the nitty gritty server admin issues).

This is great for the developer because the weight of the server admin hat that you have to wear is made a lot more manageable. The tradeoff for this abstraction is the lock-in that you have to endure as a developer.

I'm not familiar with other PaaS providers - my only experience is with Google AppEngine so I can only speak to that.

On Google AppEngine you are required to write your app using languages that are supported on the platform e.g. Java, Python, etc.

In addition to being restricted to writing your app in specific languages, your data must be stored in formats available in that platform. In the early days of AppEngine this was restricted the Datastore database.

Trading for all these drawbacks is the huge benefit of not having to handle the tiny details of administering servers. For a one-man development team, the value cannot be overstated.

However, being on a specific platform means there are quirks on the platform that you have to deal with.

This is similar to learning a new language - there are always strange quirks that you only encounter after you have worked with it deeply enough.

One example of this is the header length limit imposed by AppEngine. When I was trying to send some data as a HTTP response header, I realised that my client was unable to get the expected data from the response.

I can't remember exactly how I came across this problem but my impression was that this limit was only imposed in the actual deployment but not on the development server.

So after some Googling, I came across this StackOverflow post ( http://stackoverflow.com/questions/15280027/is-there-a-size-limit-for-http-response-headers-on-google-app-engine). So it seems that there is a limit of 497 characters that can be placed in the response header (including the colon and the space after it). Exceeding this limit meant that the header would be dropped.

I thought I would have come across this from Google's documentation but clearly not. To Google's credit, the documentation is thorough but sometimes, certain pieces of information need to be made more obvious so that developers are not caught off guards.

openssl x509 -in proxy.cer -inform der -outform pem -out proxy.crt

This command basically converts a binary certificate into a base64-encoded one (i.e. text).

The openssl command is the Swiss Army knife of encryption tools. It can encrypt/decrypt files as well as manage certificates that are used for secure connections on the Internet.

This command that I've posted does one thing - it converts a certificate from its binary form into a text form (base64-encoding).

Prior to posting this, I've done my research and have encountered this command before. The problem is the pages that I've read does not state it as simply.

Pages that I've read simply say that the above command changes the DER format of the certificate into the PEM format without going into details what the PEM format is. After some trial-and-error, I realised that in very layman terms, the PEM format is a text representation of the certificate.

Other commands that might be useful

openssl x509 -in file.cer -inform der -text -noout

Presents the information (-text) in the certificate (x509) that is the file (-in file.cer) which is in a binary format (-inform der). Omit the certificate from the output (-noout) - this option is not required.

openssl dgst -md5 file

Creates a MD5 (-md5) checksum (dgst) of a file (file)

openssl enc -aes-256-cbc -a -nosalt -in infile.jpg -out outfile.jpg.enc

This command encrypts (enc) a file (-in infile.jpg) using the AES 256-bit cipher block chaining cipher (-aes-256-cbc) with no salt (-nosalt) into a base-64 format (-a) and saves the output as a file (-out outfile.jpg.enc).

(Omit the -a switch to keep it in binary format which is almost always smaller than the equivalent binary format.)

openssl enc -d -aes-256-cbc -a -in outfile.jpg.enc -out newfile.jpg

This is the reverse operation: decrypts (enc -d) a file (-in outfile.jpg.enc) using the same cipher (-aes-256-cbc) from a base-64 format (-a) and saves the output into a file (-out newfile.jpg).

For a list of ciphers:

openssl list-cipher-commands

1. Is the person Competent, with adequate skills and experience to carry out the role you are recruiting for?
2. Are they Capable of delivering for you through good times and bad?
3. Will the candidate be Compatible with others and build good relationships with team members, managers and clients?
4. Do they have the Commitment to make a telling long-term contribution to your company, or do they bounce from job to job?
5. What is their Character and do they have personal ethics such as honesty and integrity?
6. Will they fit into your company’s Culture and live up to the expectations you have as an employer?
7. And lastly, agree on a Compensation package and make sure it is a satisfactory outcome for both parties.

(Note: The list above is copied word-for-word from the article I read. I can’t link to the original article because I received it in my email.)

One takeaway point from the article is that the interviewer can begin by first soliciting feedback from customers about the company. Knowing what are the positive things from the customers’ point of view will help the interview process by highlighting the positivity of the company.

Another suggestion in the article is to always interview candidates before the company needs the manpower. This may be preferable for large companies but is quite infeasible for small companies.

There is a point that I completely agree with, however - make sure you like the person. This does not mean that you hire only people who suck up to you. Rather, the person needs to be compatible with the company culture. If you hire solely on the basis of technical competency and aptitude you would eventually end up with someone who is difficult to work with. When that happens, not only does it make time in the office more unpleasant, but more importantly, you end up spending more time arguing and justifying the actions that you need to make rather than taking action immediately.