Blog

[MCV] Taccia Hokusai Sabimidori (Rusty Turquoise) Ink

Jun 30, 2025 - 4 min read - 500 words

Inori

Learn About Sheen

I came across the word “sheen” in the world of fountain pen ink when I browsed r/Calligraphy on Reddit. At the subreddit, I regularly saw someone’s posts using this kind of ink with great, beautiful sheen. (And his great masterpieces absolutely.) This guy I called him Lambroghini because of his reddit account, but maybe it’s proper to call him Leonardo, as indicated in his Instagram profile.

I got impressed by a ink he used in his post, which is Tesla Coil made by Birmingham Pen Company in US.

The color and sheen shown below: (official image)

tesla coil ink official image

Bump Into Sabimidori

Recently I went to a local fountain pen shop, I asked the stuff if they sell the Tesla Coil ink. They said they don’t sell any Birmingham inks. I also took a look on local shopping sites, amazons (US & Japan), nothing found. And sadly, Birmingham’s official website does not support international shipment. Oh, NO!

Then I asked the stuff to recommend similar inks with sheen. (But not limited to similar color) He recommend two inks, both of them are the Ukiyo-e ink series made by Taccia:

Hiroshige Ruri (広重(ひろしげ)瑠璃(るり))
Hokusai Sabimidori (北斎(ほくさい)錆緑(さびみどり))

PS. For more detailed and professional review about these inks, I recommend reading posts from Mountain of Ink. (Ink Review #1348: Taccia Hokusai-sabimidori — Mountain of Ink and Taccia Hiroshige Inks — Mountain of Ink)

And I love the color of Hokusai Sabimidori at the first sight, almost decided to buy it immediately. 😆

Unboxing

Here we started from the box! The design of box is inspired by Ukiyoe from Japan.

Let’s open it!

A bottle of ink and a pamphlet. Here’s all we have.

Inside the pamphlet is a brief introduction about Ukiyo-e series.

Actually there are already 16 inks in the series at the time writing. (Jun/2025)

About The Naming

I just want to discuss a little bit about the name: Hokusai Sabimidori.

For Hokusai (北斎(ほくさい)), as wiki suggests, is a Japanese ukiyo-e artist.

As Sabimidori (錆緑(さびみどり)), it can be divide into two characters. Sabi (錆(さび)) means rust in Japanese, while midori (緑(みどり)) means green.

So sabimidori means rust green, or rusty green.

Trying the Ink

It’s time to try the ink! I tried it on two paper: Midori MD and Tomoe River.

The rusty sheen is soooo beautiful!

Dry And Wet

I realize the ink will change the color when drying:

As you can see, when the ink is wet (lower stroke), it looks like Prussian blue. Then after it drys, it becomes green, which is between turquoise and emerald , but more close to turquoise. And of course with rust at ink pond!

Here’s final shot!

DEFINITELY LOVE IT!

Thanks for reading. Happy writing!

[MCV] Intro to My Calligraphy Voyage

Jun 10, 2025 - 1 min read - 100 words

Inori

This series are talking about my experiences, notes, thoughts when learning calligraphy.

As an lefty, faced many difficulties and might have different learning paths from right-handed people.

So I decided to write down something to share with people interested in calligraphy, especially lefty fellows. 😆

The series should have a name to make it easy to memorize, I call it “My Calligraphy Voyage”, abbreviated with “MCV”.

Last words to say:

Keep smudging, keep your hands dirty and enjoying calligraphy. 😎

Happy writing!

[MCV] My Equipment for Calligraphy

Jun 10, 2025 - 3 min read - 500 words

Inori

Here I just want to share what I used to practice calligraphy.

The list might be changed in the future, I will go back and update it if I remembered.

my equipment

Pen

I started learning calligraphy by buying my first Pilot Parallel pen (3.8mm). I have also tried dip pen, and sold it after giving it a try, only found that not suitable for myself as a lefty. Until now, my main pen are all Pilot Parallel pens. Other pens are not mainly used for calligraphy, they are used as auxiliary purpose.

Here’s my pen list:

Pilot Parallel pen 3.8mm: mainly used
Pilot Parallel pen 3.8mm: mainly used
Pilot Parallel pen 5.0mm
Pilot Parallel pen 1.2mm
Pilot Shaker Mechanical pencil 0.5mm: for drawing guidelines
Pilot Super Knock 0.7mm (BPK-P-WFBA): for drawing guidelines
Pilot Super Grip G 1.6mm (BPS-GG): for drawing guidelines

“Why all pens are Pilot?”, you might ask. I realized it when I made the list, it was just coincident. 🤣 I just bought pens that suitable for my writing habits. By the way, if you really want to know, my favorite brand of pen is Zebra when I was a student. But that was for hand writing, not calligraphy.

Ink

For ink now, I don’t have too much right now.

Pelikan 4001 (blue black)
Parker Quink (black)

Blue inks are suitable for practicing and learning in my opinion.

I am not a ink collectors like many people do on Reddit r/calligraphy. But willing to join them if necessary. 😆 Only when I get huge improvement of my calligraphy skill and would like to write some cards to friends, it’s better to expand the color options to make more fun. The inks Pilot Iroshizuku (色彩雫) series from Japan have many choices and they looks beautiful. (from color and naming aspect) Inks with great sheen like Diamine from UK looks beautiful, too. I really want to give them a try in the future.

Paper

Paper is another important equipment for calligraphy.

MIDORI Paperpad A5 size: MIDORI is a famous brand from Japan in stationary fiel, no need to explain more here.
Xiangqiu (象球牌) paper for fountain pen: It’s the paper produced by a brand in Taiwan. It seems pretty famous at local writing community for great writing experience with fountain pen. Further more, the price is very cheap, suitable for daily practice.

Other

Some tools worth to mention:

LED light table: china brand, with color temperature control, brightness control, magnetic pin supported
COX plastic ruler 40cm
Writing pads: brand from Tylee Pen Shop (famous stationary shop, mainly focus on fountain pens & inks)
Pen tray: preventing pens from rolling around at desk
Ink injector (refiller)

That’s all! Thanks for reading!

Happy writing! ✍️

Type Safety and Runtime Safety Part.1/2: model, validator & data

Mar 17, 2024 - 4 min read - 800 words

Inori

TypeScript makes JavaScript even stronger with a strongly-typed system, which is a merit for developers. TypeScript checks our static code before running it. That is so called type safety. However, runtime safety is checking our code at runtime with real data. In runtime, TypeScript files are already compiled to JavaScript. So static type check is not available.

It means: type safe does not mean runtime safe

The post is divided into two parts.

In part 1 here, I want to discuss about runtime validation. And in part 2, I want to share some use cases with Nuxt3 as example.

Prerequisite

Basic knowledge: JavaScript, TypeScript, zod

A Story

It starts with a story. Here we have two developers, John & Bill.

John wrote a utility function and shared to his team:

1
export function printList(list: (string | number)[]): void {
2
  list.forEach((item) => {
3
    console.log(item);
4
  });
5
}

The parameter list is limited to array, TypeScript will take an eye on everyone who call this function, and check if type of list is correct. It seems no problem to John. So he transpiled it into JavaScript, here is the result:

1
"use strict";
2
Object.defineProperty(exports, "__esModule", { value: true });
3
exports.printList = void 0;
4
function printList(list) {
5
    list.forEach(function (item) {
6
        console.log(item);
7
    });
8
}
9
exports.printList = printList;

One day, Bill imported this file to use printList function:

1
const { printList } = require("./utils.js");
2

3
const myList = [1, 2, 3, "a", "b", "c"];
4

5
console.log(printList(myList));
6

7
const myIllegalData = "hello"; // <-- this is illegal!
8

9
console.log(printList(myIllegalData)); // <-- will throw error

Without type definition, Bill used illegal parameter accidentally, then the function was broken after ran it:

runtime error

When John created the function, he expected the parameter should be an array. But someone may use it in the wrong way. (without type definition file *.d.ts)

Expected parameter is different with actual parameter, which means type (or model) is different from data. I call it mismatch (or misalignment) between type and data personally. If John did runtime check, the function would be unbreakable.

Runtime Validation

It is crucial to do runtime check, more then type check in my own opinion. As an frontend developer, we always get data from outside our code, mostly from API. External sources are likely to change or update without notifying us. So it is important to do validation right away when we got some data.

I recently use a validation library called zod, which is very suitable for runtime validation.

As the documentation introduced itself:

TypeScript-first schema validation with static type inference

It has good capability to TypeScript, and can do validation with type inference.

From Model, Validator To Data

Personally, I would like to define a model first, because model is the blueprint of data. Second, we need validator to validate the data at runtime. Since I am using zod, it is very typed-friendly to infer an validator with model. Then when receive data, we use the validator to do the validation.

Here we have three parts:

Model: Using type definition in TypeScript.
Validator: Using zod to build up validators.
Data: Validate the data using validators.

In fact, both model and validator make restriction to the data. The difference is, models restrict data statically (before runtime), validators restrict data dynamically (at runtime). Besides, validators can do stricter restriction than what models do. I will explain it later.

As Single Source of Truth or SSOT, our truth here is the model. The shape of a validator is inferred by the model, no matter what other strict validation we put on, it is still under restriction of the model. Then the data should follow the rule that validator provided.

Define the Model

Model is a blueprint of data, or origin of data. Each data value might vary, but data type should remain the same.

For example we have a model User to define what a user should look like:

1
enum Gender {
2
  Male,
3
  Female,
4
  Other
5
}
6

7
type User {
8
  name: string;
9
  age: number;
10
  gender: Gender;
11
}

So an user includes name, age, gender as above:

Name is defined as string with no doubt.
Age is a number, an positive integer actually, but TypeScript only provide number type, so we have no choice.
Gender is defined as an enum called Gender, actually it is also a number.

Define the Validator

Here we use zod to build the validator, zod will check the validator with the type we provided:

1
const userValidator: z.ZodSchema<User> = z.object({
2
  name: z.string().min(1),
3
  age: z.number().int().nonnegative(),
4
  gender: z.nativeEnum(Gender),
5
})

As we can see, in validator, we define our value precisely:

Name: Empty string is not allowed.
Age: Only nonnegative integer is allowed. No -5 year old, no 15.5 year old.
Gender: Here we only have male (0), female (1), other (2), other values are not allowed.

Here is what I said validator is stricter than model.

Execute the Validation

After that, we can validate data with it at anywhere we want:

1
const userValidation = userValidator.safeParse(userData);
2

3
if(userValidation.success){
4
  // validation is passed, congrats!
5
  // ...
6
} else {
7
  // validation is not passed, throw error, print logs or do anything to handle errors
8
  // ...
9
}

So we have much confident with our code right now! No more fear about being bombarded by illegal data!

In the next part, I want to discuss with some use cases.

Hope this post is helpful to you!

Happy coding.

Reference

Type Safety and Runtime Safety Part.2/2: page, route guard & API

Mar 17, 2024 - 5 min read - 1000 words

Inori

The post is divided into two parts. If you want to read part 1 first, please go to here.

As part 1 is about runtime validation. Part 2 will focus on use cases. I will use Nuxt3 as example.

Here I have 3 use cases: page, route guard (Vue route) and API.

Prerequisite

Basic knowledge: JavaScript, TypeScript, Nuxt3, Vue3, zod

Case 1: Page Validation

Suppose we have a post list page with route: /posts?page=3&sort=desc&limit=20.

Then let’s define the route parameter model:

1
enum Sort {
2
  ASC = 'asc',
3
  DESC = 'desc',
4
}
5

6
// PS. RP means route parameter, which is my naming preference.
7
interface RPPostList {
8
  limit?: number;
9
  page?: number;
10
  sort?: Sort;
11
}

And validator:

1
const RPPostListValidator: z.ZodSchema<RPPostList> = z.object({
2
  limit: z.coerce.number().int().positive().max(50).optional(),
3
  page: z.coerce.number().int().positive().optional(),
4
  sort: z.nativeEnum(Sort).optional(),
5
});

The data we plan to validate is from url. That means we will only get value with string type. So the values from page and limit should be transformed into number before validate it. Otherwise, we will get "3" instead of 3 from page. Thankfully, the latest version of zod has coerce method, we can transform it easily.

page: page means current page number, so it should be positive integer.
limit: limit means how many items per page, which is also a positive integer. Besides, it is limited to 50 as maximum value due to performance concern. Of course we can define it in the backend.
sort: sort is limited to desc or asc.

In the page component, here is the process:

We get query string from url with route.query in Nuxt3.
Validate the query string.
After safely parsed the data, we can do whatever we want.

Here is an example:

1
<script setup lang="ts">
2
import { SafeParseReturnType } from 'zod';
3

4
const route = useRoute();
5

6
const queryStringValidation = computed<SafeParseReturnType<RPPostList, RPPostList>>(() =>
7
  RPPostListValidator.safeParse(route.query),
8
);
9

10
const currentPage = computed<number>(() => {
11
  if (queryStringValidation.value.success) {
12
    // if query string has page, return page, otherwise, return 1
13
    return queryStringValidation.value.data?.page ? queryStringValidation.value.data.page : 1;
14
  } else {
15
    // if validation failed, return 1 whatsoever
16
    return 1;
17
  }
18
});
19

20
const currentSortType = computed<Sort>(() => {
21
  if (queryStringValidation.value.success) {
22
    return queryStringValidation.value.data?.sort ? queryStringValidation.value.data.sort : SortingEnum.DESC;
23
  } else {
24
    // if validation failed, return desc as default sorting
25
    return Sort.DESC;
26
  }
27
});
28
</script>

For currentPage, if query string didn’t have page value, or giving something strange page like ?page=-1, ?page=hello, then we will give page number 1 as default. Same as currentSortType.

Case 2: Validation in Route Guard

Consider we have a post page with route: /post/:id.

The route middleware in Nuxt3 will triggered before entering the page. So it is very suitable to make a route guard using route middleware.

1
import { z } from 'zod';
2

3
// PS. RP means route param, which is my naming preference.
4
interface RPPost {
5
  id: number;
6
}
7

8
const RPPostValidator: z.ZodSchema<RPPost> = z.object({
9
  id: z.coerce.number().int().positive(),
10
});
11

12
export default defineNuxtRouteMiddleware((to, _from) => {
13
  const isValid: boolean = RPPostValidator.safeParse(to.params);
14

15
  // if validation failed, redirect to home page
16
  if (!isValid) {
17
    return navigateTo('/');
18
  }
19
});

As the validator shown above, id is considered as post id. The post id in our database will be PK, or primary key. And primary keys are positive integers. So it is unnecessary to go to page like: /post/-123, /post/2.35 or /post/hello. Without asking the database, we have confidence to say that there’s no such a post in our database. So we can directly redirect it to home page or error page.

Incoming url might be various and unpredictable. (Or should I say untrustable? Sounds like a skeptic, LOL.) So it is safer to do strict check before we use it.

Speaking of untrustable, it remind me of an quote from a great assassin Altair, once he said:

Nothing is true, everything is permitted.

Altair

Here we can say:

Nothing is true, everything should be validated. 🤘

Case 3: API Validation

When encounter an API, I asked myself:

Which data is unsafe and needs validation?
When each validation failed, how to handle the error?

Until now, the process below is what I think as a good practice:

Validate incoming payload: from route params & query string
If failed, throw 400 bad request
Query data, DB connection
Validate raw data
If failed, throw 500 internal server error
Return data as response

Here’s an Nuxt3 server API for querying single post data. The endpoint is /api/post/:id using GET http method. To demo, I gathered all models and validators together for easy reading. For real world use, they will be placed in other directory respectively.

1
import { z } from 'zod';
2

3
interface RPPost {
4
  id: number;
5
}
6

7
const RPPostValidator: z.ZodSchema<RPPost> = z.object({
8
  id: z.coerce.number().int().positive(),
9
});
10

11
// PS. M means model, which is my naming preference.
12
interface MPost {
13
  id: number;
14
  content: string;
15
  publishAt: Date;
16
  title: string;
17
}
18

19
const MPostValidator: z.ZodSchema<MPost> = z.object({
20
  id: z.number().int().positive(),
21
  content: z.string(),
22
  publishAt: z.date(),
23
  title: z.string().min(1),
24
});
25

26
// Nuxt3 server API
27
export default defineEventHandler(async (event) => {
28
  // Step 1 - get payload from router, query string or request body
29
  const params = getRouterParams(event);
30

31
  // Step 2 - payload validation
32
  const routerParamValidation = RouterParamValidator.safeParse(params);
33

34
  // Step 3 - if validation failed, would throw 400 bad request
35
  if (!routerParamValidation.success) {
36
    throw createError({ message: 'Request is invalid.', statusCode: 400 });
37
  }
38

39
  // Step 4 - db connection query method defined at another place
40
  const rawData = await getPostById(routerParamValidation.data.id);
41

42
  // Step 5 - raw data validation
43
  const rawDataValidation = MPostValidator.nullable().safeParse(rawData);
44

45
  // Step 6 - if validation failed, would throw 500 internal error
46
  if (!rawDataValidation.success) {
47
    throw createError({ message: 'Data and model mismatched.', statusCode: 500 });
48
  }
49

50
  // Step 7 - everything is fine, then transform data into view model, then return it
51
  return rawDataValidation.data;
52
});

An API also get url like route middleware does. So they might share the same route param model and validator. Besides, if accepted request body like POST API, it should also validate request body, too.

If route params was illegal, throw 400 bad request error to user. And if it passed the validation, then continue to the next step: connect with external source (like database, APIs) to get data.

Since we may get data from several external source listed below:

From our database directly.
From APIs created by our backend colleagues.
From third party APIs.
…any other external sources you might need.

There are some concerns about the data from each source:

Database: database might stored dirty data under development or other reasons.
APIs from backend: Your backend colleagues updated their data model or adjusted their APIs, but forgot to inform you. Human makes mistakes.
Third party APIs: Third party APIs might change their response, and of course the provider is not obligated to notify everyone who use it, especially free APIs.

So it is much safer to validate the raw data before using it.

If validation failed, throw 500 internal server error error to user if necessary. Maybe throw a 500 error might be too radical for someone. If so, another choice is to just log error down without throwing an error.

But what I concerned here is, any kind of dirty data (no matter how small it is) might have risks to break front end page. A frontend developer might murmur like this: The page was good yesterday, why is it broken today? I didn’t touch anything… WHY?!

So, the stricter the better.

After all validations passed, we are good to go: returning back as a response.

Conclusion

Validation process might be tedious, but it is worthy in the long term. Maybe it is frustrated. But it is more frustrated when we get a bomb (dirty data) that crash our page at any unexpected time… (Saying when we are going to sleep.)

validation everywhere

Since I played Minesweeper and got GAME OVERS some many times when developing, it is time to face the music. Then it leads me to the ideas mentioned above. Hope it is helpful!

Happy coding.