Forem: Rungsikorn Rungsikavanich

ใช้ node module 2 version ใน project เดียวกัน

Rungsikorn Rungsikavanich — Fri, 17 Jun 2022 17:43:42 +0000

วันนี้เล่านิดหน่อย เรื่องทำยังไงถึงจะใช้ node module อันเดียวกัน แต่ 2 version ได้ ภายใน project เดียว

ไปเจอว่าถ้าใช้ lerna จะทำให้ node module ของแต่ละ sub packages ใช้ version แยกกันได้ ตามภาพเลยเด้อ (จะเห็นว่า ซ้ายใช้ spl-token@0.1.8 แต่อีกด้านใช้ spl-token@0.2.0

พอใช้งานรันจริงก็จะเห็นว่า มันเรียกใช้ node module ของใครของมัน ถึงแม้ว่าจะ link deps เข้าหากันก็ตาม

วิธีใช้ก็แค่

lerna add @solana/spl-token@0.1.8 --scope=module-a
lerna add @solana/spl-token@0.2.0 --scope=module-b
lerna link
lerna add module-a --scope=module-b

Reference

https://github.com/lerna/lerna

😎 😎 😎 😎

STOP USING window as any

Rungsikorn Rungsikavanich — Mon, 09 May 2022 10:06:42 +0000

TLDR;

for someone who have a limit of time



// instead of this
(window as any).MY_GREETING_MESSAGE = 'Hi Earth!'
// do this
declare global {
    interface Window { 
         MY_GREETING_MESSAGE: string
    }
}
window.MY_GREETING_MESSAGE = 'Hi Earth!'

You guys typescripter might came across the situation that you need to put something into a global scope variable like window

For javascript you may easily put something into it without any complicated step like.



// running in browser
window.MY_GREETING_MESSAGE = 'Hi Earth!'

but as Typescript which will do some type checking if any object attribute you are working on is really existed in the view of the static type language. you will be forbidden to do this directly.



window.MY_GREETING_MESSAGE = 'Hi Earth!'
// ^^
// Property 'MY_GREETING_MESSAGE' does not exist on type 'Window & typeof globalThis'.ts(2339)

Why?

The answer is pretty straight, because the interface Window which declare for this global window variable does not have MY_GREETING_MESSAGE property

Here come the `window as any`

for most of new Typescript developer may unable to solve this issue and put this dirty workaround like explicitly cast window to any which means we will access window without any type safety and no type checking in the runtime!



(window as any).MY_GREETING_MESSAGE = 'Hi Earth!'

Bring back the type

As window has been declared by the standard Ambient type from Typescript library. The better approach is to extend this type like this



declare global {
    interface Window { 
         MY_GREETING_MESSAGE: string
    }
}
window.MY_GREETING_MESSAGE = 'Hi Earth!'

and this will let Typescript recognize the property you want to put into the ambient window object

noted that you need to make sure the value has been assigned before use, or you may make it as an optional property

Happy Coding!

How to proper use ambient enum from Definition file

Rungsikorn Rungsikavanich — Mon, 25 Apr 2022 06:39:14 +0000

If you guy need to declare your enum in definition file you may encounter a weird behavior and lead to something like this

/// module A
/// types.d.ts
export enum MyEnumA {
     A = "A"
}


/// module B
/// main.ts
import { MyEnumA } from 'A'
console.log(MyEnumA.A) 
// TypeError: cannot read property 'A' of undefined

Why?

In the nutshell, Definition file cannot be reference as value and that is why they call it 'Ambient'

How to properly solve it?

`const enum` solution (Not recommended)

If your project have a very simple setup. You may able to use the typescript feature call const enum which

const as a prefix of enum will turn this enum into an inline constant in compiler time.

/// module A
/// types.d.ts
export const enum MyEnumA {
     A = "A"
}


/// module B
/// main.ts
import { MyEnumA } from 'A'
console.log(MyEnumA.A) 

/// module B compiled
/// main.js
console.log("A") // <<< here is the hardcoded value from enum

But why this approach is not recommended?

this approach does not support isolatedModule option
as MyEnumA.A is transpile into a hardcoded value. if module B enum value is change, you need to recompile module A again to update the hardcoded value
Typescript team does not recommend it https://www.typescriptlang.org/docs/handbook/enums.html#const-enum-pitfalls

Declare ambient value in global scope (Recommended)

The proper solution is to assign this enum value ambient. As ambient is just an abstraction, in the implementation file you need to assign this value as you declare in ambient too.

So we will declare enum in definition file as an ambient and assign value into global scope variable

/// module A
/// types.d.ts
declare enum MyEnumAValue { // ambient enum
     A = "A"
}
declare var MyEnumA: typeof MyEnumAValue // ambient value

/// module B
/// types.ts as ambient value file
enum MyEnumAValue {
    A = 'A'
}

window.MyEnumA = MyEnumAValue; /// this will be checking with ambient if enum value is consistent with ambient enum
// or
global.MyEnumA = MyEnumAValue;


/// main.ts
import 'A'
console.log(MyEnumA.A)

Here is how the type checking work

Consistent

Inconsistent

Summary

If you want to use a type definition file and you want to declare enum in it.

in the implementation file you need to assign the value as you declare in the ambient too.

The best way to do it is assign the enum value to global scope variable.

Terra Network SmartContract Migration

Rungsikorn Rungsikavanich — Sun, 31 Oct 2021 14:50:45 +0000

Terra network มีอัพเดทครั้งใหญ่ เพื่อเพิ่มประสิทธิภาพของ Network แต่ในบทความนี้ ผมจะไม่พูดเรื่อง Network แต่จะไป focus เรื่อง Smart Contract แทน โดยถ้าอยากรู้ว่ามีอะไรเปลี่ยนไปบ้าง ลองดูได้ลิ้งนี้แทน

https://medium.com/terra-money/columbus-5-launches-welcome-to-the-future-of-terra-8a9ebfa570c5

หนึ่งในการอัพเดทคือการ Bump cosmwasm ไปเป็น version 0.16 ( ซึ่ง breaking change กระจาย ) เรามาดูกันว่า เราต้องเปลี่ยนอะไรบ้างจาก contract version เดิม ( 0.10 )

นอกจากนี้ feature ที่เพิ่มมาก็เยอะมาก เพราะมัน upgrade กันข้ามมา 6 version ถ้าต้องการไล่อ่าน ตามไปที่ https://github.com/CosmWasm/cosmwasm/blob/main/CHANGELOG.md ได้เลย

ของ Avareum protocol พังไป 240 errors 😱

มีอะไรเปลี่ยนไปบ้าง?

API มีความกระชับขึ้น Type ต่างๆ Generic ต่างๆใช้ง่ายขึ้น
Support การทำ Migration ผ่าน Contract ได้แล้ว

โดยบทความนี้จะยกเอาแค่ Major change หลักๆ ที่ทีม Avareum ต้อง Migrate ซึ่งทางทีมก็ยังใช้ Feature ของมันไม่หมด (เยอะเกิน)

Support On-chain Contract Migration

อันนี้คือที่รอคอยมานาน ซึ่งพึ่งมาเพิ่มใน coswasm 0.14 ทำให้ Contract สามารถ Migrate กันเองได้แบบ On-chain

โดยที่ก่อนหน้านี้ จะจำกัดเรื่องการ migrate contract สามารถทำได้โดยผ่าน Off Chain API อย่างเดียว ทำให้ต้องเป็นหน้าที่ของ Owner ของ Contract เท่านั้นที่สามารถ Migrate ได้และหากมีหลาย Contract ก็ต้องทำทีละอันจาก Off chain

จาก Feature นี้ทำให้เราสามารถ Deploy contract set ที่มี Logic ในการ ทำ Migration ออกมาและสั่ง Migrate ที่เดียวจาก Off chain จาก Entrypoint ที่เดียว

#[cfg_attr(not(feature = "library"), entry_point)]
pub fn migrate(deps: DepsMut, _env: Env, msg: MigrateMsg) -> Result<Response, ContractError> {
    let cfg = query_config(&deps.as_ref())?;
    Ok(Response::new().add_messages(vec![
        CosmosMsg::Wasm(WasmMsg::Migrate {
            contract_addr: cfg.executor_mirror_address.into(),
            new_code_id: msg.sub_contract.executor_mirror_code_id,
            msg: to_binary(&msg.sub_contract.executor_mirror_migrate_msg)?,
        }),
        CosmosMsg::Wasm(WasmMsg::Migrate {
            contract_addr: cfg.executor_anchor_address.into(),
            new_code_id: msg.sub_contract.executor_anchor_code_id,
            msg: to_binary(&msg.sub_contract.executor_anchor_migrate_msg)?,
        }),
        CosmosMsg::Wasm(WasmMsg::Migrate {
            contract_addr: cfg.executor_terraswap_address.into(),
            new_code_id: msg.sub_contract.executor_terraswap_code_id,
            msg: to_binary(&msg.sub_contract.executor_terraswap_migrate_msg)?,
        }),
    ]))
}

วิธี binding Entrypoint เปลี่ยนใหม่

จากปกติก่อนหน้านี้ การกำหนด entrypoint ทั้งหมดจะอยู่ที่ lib.rs ให้ลบตรงนั้นทิ้งออกให้หมดแล้วไปใช้ macro กับ function ชื่อ entry_point แทน
พร้อมกับ เปลี่ยนชื่อ init เป็น instantiate และ handle เป็น execute

https://github.com/CosmWasm/cosmwasm/blob/main/CHANGELOG.md#changed-6


#[cfg_attr(not(feature = "library"), entry_point)]
pub fn instantiate(
    deps: DepsMut,
    _env: Env,
    _info: MessageInfo,
    msg: InitMsg,
) -> Result<Response, ContractError> 
....


#[cfg_attr(not(feature = "library"), entry_point)]
pub fn execute(
    deps: DepsMut,
    env: Env,
    info: MessageInfo,
    msg: ExecuteMsg,
) -> Result<Response, ContractError> {

...

Extern API เปลี่ยนเป็น Deps และ DepsMut

จากการใช้งาน Extern กับ Generic type ทาง cosmwasm ได้เปลี่ยนมาเป็น type alias ทำให้ ปกติที่ใช้ Extern ให้เปลี่ยนเป็น Deps และ mut Extern เปลี่ยนเป็น DepsMut
Reference

ตัวอย่าง

จาก

pub fn init<S: Storage, A: Api, Q: Querier>(
    deps: &mut Extern<S, A, Q>,
    _env: Env,
    msg: InitMsg,
) -> StdResult<InitResponse> {

เปลี่ยนเป็น

pub fn init(
    deps: DepsMut,
    _env: Env,
    msg: InitMsg,
) -> StdResult<InitResponse> {

จากอันนี้ การ access funds ที่ส่งมาจะเปลี่ยนจาก access ที่ env ไปผ่านตัว info แทน

เพิ่ม Arguments ให้กับ Contract entry point ( init, handle, migrate )

Type Env ถูกนำเอา sender ออกและย้ายไปไว้ใน Type ชื่อ MessageInfo เข้าใจว่าเพื่อให้เป็นระเบียบมากขึ้นเฉยๆ

ตัวอย่าง

จาก

pub fn handle(
    deps: DepsMut,
    env: Env,
    msg: HandleMsg,
) -> StdResult<HandleResponse> {
.....
    let senderAddr = env.message.sender;

เปลี่ยนเป็น

pub fn handle(
    deps: DepsMut,
    env: Env,
    info: MessageInfo,
    msg: HandleMsg,
) -> StdResult<HandleResponse> {
.....
    let senderAddr = info.sender;

Migrate Response, HandleResponse, InitResponse กลายเป็น Response เฉยๆ และเป็น non_exhaustive

มีการรวม Response ต่างๆเป็นอันเดียว และใช้ Higher order function ในการ assign parameter ต่างๆให้กับ Response ( ไม่อนุญาตให้สร้าง Response แบบ struct expression แล้ว

ซึ่งผมชอบนะอันนี้ ดูกระชับขึ้นเยอะเลย ( ถึงจะต้องแก้ Contract เก่าเยอะหน่อย )

จาก

use cosmwasm_std::{ HandleResponse };

.....

 Ok(HandleResponse {
        messages: msgs,
        data: Option::None,
        attributes: logs,
    });

เปลี่ยนเป็น

use cosmwasm_std::{ Response };

.....

    Ok(Response::new()
        .add_attributes(logs)
        .add_messages(msgs))

Log API เปลี่ยนชื่อเป็น Attribute

version 0.16 เอา log ออกหมดเลย เปลี่ยนไปเรียกว่า Attribute แทน รวมถึงการ return log จาก response ก็จะเปลี่ยนไปใช้ add_attributes หรือ add_attribute จาก Response แทน ( เพราะว่า HandleResponse ถูก Deprecated ไปแล้วจากด้านบน

-- let logs: Vec<LogAttribute> = vec![log("label","value")];
++ let attrs: Vec<Attribute> = vec![attr("label", "value")];

-- HandleResponse { log: logs }
++ Response::new().add_attributes(attrs);

HumanAddr ถูก Deprecated

ใน API version ใหม่จะมี Addr มาแทน HumanAddr โดยที่ API ส่วนใหญ่ ที่ใช้ HumanAddr จะเปลี่ยนไปใช้ String แทนแล้ว

เช่น WasmMsg:Execute จากปรกติ รับ contarct_addr เป็น HumanAddr ตอนนี้จะรับเป็น String แทน ซึ่งหากเราตัดสินใจใช้ Addr ก็จะมี to_string ให้ใช้เปลี่ยนจาก Addr เป็น String

-- let contract_addr: HumanAddr;
++ let contract_addr: Addr;
WasmMsg::Execute {
   -- contract_addr: contract_addr,
   ++ contract_addr: contract_addr.to_string(),
}

หลักๆเราต้อง Migrate ตัว contract ประมานนี้ ส่วนใหญ่ยังไม่มีอะไรที่ Breaking Change ถึงกับขนาดต้องออกแบบ Contract ใหม่

ส่วนอื่นๆ นอกจากนี้ลึกๆ ตามไปไล่อ่านที่นี่ได้เลยจ้า
https://github.com/CosmWasm/cosmwasm/blob/main/MIGRATING.md

Project Layout ของ Golang EP.1

Rungsikorn Rungsikavanich — Sat, 12 Dec 2020 12:18:28 +0000

วันนี้จะมาเล่าเรื่อง Project Layout ครับ เรียกได้ว่าเป็นหนึ่งในสิ่งสำคัญที่จะทำให้เราพัฒนา application ด้วยภาษา Golang ได้ตรงตามที่ผู้พัฒนาต้องการให้เราทำ ( หรือ Idiomatic ที่แปลว่า ลักษณะจำเพาะ ) เพื่อให้โปรเจคเรา ใกล้เคียงความเป็น Gopher project มากที่สุดกันครับ

✨ TL;DR อีกแล้ว

Golang ไม่มี layout standard เป็นตัวเป็นตนจาก Go Core Dev team ที่มีอยู่ตอนนี้ก็คือ ตั้งแต่ Go 1.4 เป็นต้นไป folder internal จะไม่สามารถถูกเรียกใช้จากนอก package หลักได้

release note เรื่อง internal folder

นอกนั้นก็ตามแล้วแต่ผู้ดูแลโปรเจคจะเป็นคนกำหนด convention ของ layout ตัวเอง

ส่วนทางด้าน community และ open source ก็มีตัวอย่างที่ใช้กันบ่อยๆ ฮิตๆก็ดูได้จาก Repository นี้ (และ open source ของ Golang อื่นๆ)

https://github.com/golang-standards/project-layout

หลักๆคือ

cmd ใช้สำหรับเก็บ package ที่เป็น entry point ของ application (ส่วนใหญ่ก็คือ package main) โดยจะไม่นำ code มาเขียนตรงนี้เยอะ โดย package ใน cmd จะไปเรียกใช้ code ที่อยู่ในส่วนของ interal และ pkg
internal เก็บ package ที่เป็น implementation หลักของ application (หรือ library) ซึ่งไม่ต้องการให้มีการ import จากนอก package
pkg ใช้เก็บ package ที่เหมือนกัน internal แต่สามารถ import ไปใช้งานได้นอก application (หรือ library) เหมาะสำหรับใช้ reuse package ไปที่ project อื่นๆ

และนอกจากนี้ เรายังสามารถศึกษาได้จาก Open Source Project อื่นๆที่พัฒนาด้วย Golang (ดูต่อที่ Reference)

แต่ยังไงก็ตาม การทำงานที่มีประสิทธิภาพที่สุด ก็คือการทำงานบน convention ที่เราสามารถสร้าง productivity ได้มากที่สุด เพราะฉะนั้น ก็ไม่จำเป็นจะต้องทำตามสิ่งเหล่านี้ทั้งหมดครับ เราอาจจะใช้ layout ของ NodeJS หรือ Java ก็ไม่เป็นอะไร ถ้าเราสามารถ deliver งานได้ตามที่ business ต้องการ

เริ่มเนื้อหาแบบยาว...

Project Layout คืออะไร?

ในการพัฒนาแอพพลิเคชั่นแต่ละภาษา ก็จะมี Project Layout แตกต่างกันออกไปครับ เพื่อการ organize code ที่ดี แต่ละภาษาก็มี convention แตกต่างกันออกไปตาม design pattern ของภาษา

เช่นเมื่อ New Project ใน Java, C#, Swift หรือ NodeJS รวมไปถึงระดับ Framework เช่น Laravel หรือ Angular เราก็จะได้ project layout แตกต่างกันออกไป แต่ก็เพื่อให้สามารถจัดการ Code ง่ายที่สุด ตามที่ผู้พัฒนาภาษาคิดมาซึ่งส่วนใหญ่ หนีไม่พ้น ทุกแบบก็จะประกอบไปด้วย

Dependencies and Information
Implementation
Testing
Build
Distributed

เช่น Swift เราก็จะมี Podfile, xcodeproj หรือ NodeJS เราจะมี package.json, src folder

Dependencies and Project Information

สำหรับ Golang แล้ว ก่อนที่จะมี go mod เราบันทึก dependencies ไว้ภายในตัว code เอง (ใน import) แต่หลังจากนั้นก็มี tools เพื่อควบคุม version เช่น glider หรือ godeps

ปัจจุบัน Golang มี dependency management เองแล้วชื่อ go mod ซึ่งประกอบด้วย go.mod และ go.sum ภายในบ่งบอกถึง dependencies ต่างๆที่เราจะใช้งาน

ส่วน Project Information ต้องบอกก่อนว่า Golang เราทำ document ด้วยการ comment เป็นหลัก (เรื่องการทำ godoc จะเอาไว้เขียนบทความหน้า) เพราะฉะนั้น Information ของ package ต่างๆก็เลยถูกเขียนไว้ใน comment ทั้งหมด

Implementation

ส่วนที่เราเก็บ code ที่เราเขียนไว้จะประกอบด้วย 4 packages หลักๆ (จริงๆมีมากกว่านั้น แต่ผู้เขียนเลือกอันที่ใช้ และเจอบ่อยมาเพื่อความเรียบง่าย ลองดูใน Go Standard Layout เพิ่มเติมครับ)

1. cmd Folder

Folder หลักที่ใช้เก็บ Entry point package ต่างๆของ application โดยส่วนมากจะเป็น Package main โดย package ภายใต้ folder นี้ไม่จำเป็นจะต้องมี implementation ที่ซับซ้อนมากมาย ทำแค่เพียงเป็น entry point เรียก implementation อื่นๆจาก package ใน folder internal, web และ pkg

ตัวอย่างจาก Ethereum Golang

ตัวอย่างจาก Go Pkgsite

2. internal Folder

Folder นี้น่าจะเป็น folder ที่มี source code เก็บอยู่มากที่สุด (ถ้าเป็น application) เพราะประกอบด้วย implementation หลักของ Project ที่ไม่สามารถ import ผ่าน package อื่นๆนอกจาก Project นี้ได้ (หรือภายใต้ go module เดียวกัน)

ตัวอย่างจาก Go Pkgsite ซึ่ง package แน่นมาก

ถึงใน standard project layout จะบอกว่าเป็น folder ที่อยู่ด้านนอกสุด (workspace root) แต่ก็ไม่จำเป็น เพราะ Golang จะ recognize folder internal ให้ตลอด เพราะฉะนั้นไม่จำเป็นที่จะต้องอยู่ที่ workspace root ก็ได้

เช่นตัวอย่างจาก Golang source code เองก็มีการวาง folder internal ไว้ภายใน src folder ( ซึ่ง src folder ไม่ได้มีใน Standard Project Layout )

3. pkg Folder ( หรืออยู่ที่ root ไปเลย )

คล้ายๆกันกับ internal (อ่าว พูดเหมือนใน TL;DR เลย) แต่ในนี้จะประกอบด้วย code ที่สามารถนำไป reuse ใช้งานภายนอก package หลักได้

หรือบาง repository ก็ไม่ใช้เลย โดยนำเอา package ต่างๆมาไว้ที่ workspace root (ที่เดียวกับ go.mod ไปเลย) โดยมีการเถียงกันที่ issue นี้ 555555
https://github.com/golang-standards/project-layout/issues/10

ถ้าดูตัวอย่าง ส่วนใหญ่จะเป็น Library หรือ Opensource tools ต่างๆ เช่น
ตัวอย่างจาก Moby (container engine ของ docker)

ตัวอย่างจาก Kubernetes

ตัวอย่างจาก Gorilla Mux ที่ไม่ใส่ folder อะไรเลย เอาไว้มันโต้งๆนี่แหล่ะ

4. web Folder

Folder นี้จะประกอบด้วย source code ของ frontend ซะส่วนใหญ่ (ถ้าเป็น web base application) โดยเราจะเอา html template, static asset ต่างๆมาเก็บไว้ในนี้ หรือถ้าเป็น Javascript framework อย่าง Angular ก็นำมาเก็บไว้ในนี้ได้ (ในกรณี Monorepository)

ตัวอย่างจาก traefik (http engine ที่เขียนด้วย golang (คล้ายๆ nginx)

go pkgsite นั้นเอาไว้ใน content folder แทน go pkgsit repository

จบแล้วสำหรับ part แรก เดี๋ยวส่วนอื่นๆที่เหลือ จะเขียนต่อใน part ต่อไปครับ

Happy Christmas and coding!
🎄 🤖

Reference

10110 การทำ Flag ด้วย Bitset ใน Golang

Rungsikorn Rungsikavanich — Sat, 05 Dec 2020 12:45:58 +0000

โปรแกรมเมอร์รุ่นใหม่ๆ ที่ไม่คุ้นกับภาษา Go (หรือภาษาเก่าๆอื่นๆ) อาจจะสงสัยว่า ไอ้ parameter ที่มัน OR ได้นี่มันคืออะหยังหนอ

    os.OpenFile("pathtofile", os.O_APPEND|os.O_RDWR, 0755)
                                      ^^^ ไอ้นี่
    log.SetFlags(log.Llongfile | log.LUTC)
                         ^^^ ไอ้พวกนี้ด้วย

มันคือ Flags นั่นเองครับ underhood มันคือ int ธรรมดาแต่ถูกจัดการด้วย bitwise operator ซึ่งจะเป็นหัวข้อของ blog นี้

🌟 TL;DR สรุปก่อนไปเลย

ตัวอย่างสุดท้าย ใน Playground
Bitset Flag จะทำให้เราสามารถ pass enum parameter ได้มากกว่า 1 parameter โดยไม่ต้องแก้ไข signature ของ function เพิ่ม ทำให้สามารถส่ง enum เข้าไปใน function ได้โดยไม่ต้องใช้ slice

การทำ Flag ใน Golang เหมือนกับการทำ Flag ในภาษาอื่นๆ แต่ด้วยความสามารถของ iota ทำให้การทำ Flag ง่ายขึ้นนิดนึง


type flag int

const (
    flagWithA flag = 1 << iota
    flagWithB
    flagWithC
    flagWithD
)

func (f flag) has(v flag) bool {
    return f&v != 0
}

func print(flags flag) {
    fmt.Println(
        flags.has(flagWithA),
        flags.has(flagWithB),
        flags.has(flagWithC),
        flags.has(flagWithD),
    )
}
func ExampleBitsetFlag() {
    print(flagWithA | flagWithD)
    // output: true false false true
}

Flag คืออะไร

การพัฒนา application ด้วย Golang คงจะเคยเจอการใช้ Flag กันผ่านๆมาแล้ว โดยเฉพาะการ OpenFile

os.OpenFile("somedir", os.O_APPEND|os.O_CREATE|os.O_RDWR, 0655)
                        ^^^^ ตรงนี้

ใน parameter ที่ 2 จะเห็นว่าเราสามารถ pass parameter ไปได้มากกว่า 1 ตัวทั้งๆที่ parameter ตรงนี้กำหนดไว้แค่ int อย่างเดียวใน signature

// OpenFile is the generalized open call; most users will use Open
// or Create instead. It opens the named file with specified flag
// (O_RDONLY etc.). If the file does not exist, and the O_CREATE flag
// is passed, it is created with mode perm (before umask). If successful,
// methods on the returned File can be used for I/O.
// If there is an error, it will be of type *PathError.
func OpenFile(name string, flag int, perm FileMode) (*File, error) {

หลายคนที่ย้ายมาจากภาษาอื่นๆ อาจจะไม่คุ้นตากับการใช้ Flag แบบนี้สักเท่าไหร่ (เนื่องจากภาษาอื่นก็มี pattern อื่นๆในการ pass value แบบนี้แทนแล้ว)

แต่เนื่องจาก Golang พัฒนามากับความเรียบง่าย เราเลยยังเห็นการใช้ Bitset และ bitwise operator เพื่อทำ flag parameter อยู่

Bitwise Operator คืออะไร?

ในภาษาต่างๆ เราอาจจะเคยเห็นการทำ Bitwise Operator กันมาบ้าง ถ้าเป็น Developer ใหม่ๆอาจจะไม่คุ้นชินตาเท่าไหร่ (ถ้าไม่ใช่ภาษาอย่าง C หรือ C++ หรือตอนเรียนมหาลัย)

ในบทความนี้มี 3 bitwise operators ที่เราจะใช้งานกันคือ

<< left shift
& AND
| OR

Left shift operator

เครื่องหมาย << หมายถึงการขยับ bit value ไปด้านซ้าย (และกลับด้านกัน >> right shift คือขยับไปขวา)

package main
import "fmt"
func ExampleBitwise() {
    var n = 2 << 8
    fmt.Println(n)
    fmt.Println(n >> 2)
    // output: 512
    // 128
}

ในตัวอย่างจะเห็นว่ามีการ assign left shift int(2) ให้กับตัวแปร n สิ่งที่ได้จาก expression นี้คือเราทำการขยับ bit ปัจจุบันไปด้านซ้าย จำนวน 8 ตัวให้กับ int(2)

Decimal Number	Binary Number
2	10 ( มี 0 จำนวน 1 ตัว )
512	1000000000 (มี 0 จำนวน 9 ตัว )

AND และ OR operator

สำหรับการทำ AND operator เราจะได้ผลลัพธ์ออกมาเป็น bitset ที่ตรงกัน สำหรับ 2 values (intersect)

และ OR operator เราจะได้ผลลัพธ์ของ bit position ที่มีค่า (union)

ตัวอย่างเช่น

func ExampleBitsetAnd() {
    var n = 4   // this is 0100
    var nn = 12 // this is 1100
    fmt.Printf("%b %b", n&nn, n|nn)
    // output: 100 1100
}

สร้าง Enum ด้วยค่าของ bit set

จาก Operator ที่ได้เกริ่นมา จะทำให้เราสามารถเอาหลักการ bitset มาใช้แทน value ของ flags ได้ด้วยการให้แต่ละ Bit บ่งบอกถึงการเปิดและปิดของ flag ต่างๆ

ยกตัวอย่างเช่น
Function echoHello สามารถ echo Hello ในภาษาต่างๆได้

       0000  // 4 bits
       ^ first bit represents echo in English
        ^ second bit represents echo in Thai
         ^ third bit represents echo in Japanese
          ^ last bit represents echo in French

เราก็จะได้ enum ออกมาเป็นแบบนี้

const (
    EchoEN = 1 // 0001
    EchoTH = 2 // 0010
    EchoJP = 4 // 0100
    EchoFR = 8 // 1000
)

func ExampleEchoHello() {
    // ส่ง 1011 เข้าไป
    echoHello(EchoEN | EchoTH | EchoFR)
    // output: Hello
    // สวัสดี
    // Bonjour
}

func echoHello(flags int) {  // flags input คือ 1011
   if flags&EchoEN != 0 { // ผลลัพธ์ของการ 1011 AND 0001 คือ 0001
      fmt.Println("Hello")
   }
   if flags&EchoTH != 0 { // ผลลัพธ์ของการ 1011 AND 0010 คือ 0010
      fmt.Println("สวัสดี")
   }
   // .... do the rest of logic
}

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

ใช้ `iota` และ เปลี่ยนจาก int เป็น type ใหม่เพื่อให้ bitset ใช้งานง่ายขึ้น

จาก code ด้านบนจะเป็นการเขียนโปรแกรมตรงๆ ไม่ได้ใช้คุณสมบัติอะไรพิเศษจาก Golang ตอนนี้เราจะมาใช้คุณสมบัติของ Golang ให้ bitset flag เราใช้งานง่ายขึ้น

เริ่มจาก ประกาศ enum และ left shift โดยใช้ iota (คีย์เวิร์ดสำหรับทำ successive integer หรือเลขที่เพิ่มขึ้นเรื่อยๆ อธิบาย successive integer

const (
    EchoEN = 1 << iota // 1 << 0 = 0001
    EchoTH             // 1 << 1 = 0010
    EchoJP             // 1 << 2 = 0100
    EchoFR             // 1 << 3 = 1000
)

จากนั้น เพื่อทำให้ง่ายต่อการเช็ค bit เราจะทำ type ใหม่สำหรับ Echo Flag และเขียน function เพื่อตรวจว่า bitset นั้นมี enum ที่เราอยากรู้มั้ย

type EchoFlag int
func (e EchoFlag) has(f EchoFlag) bool { 
     // ตัวอย่างถ้า e มีค่า = 12 ( 1100 )
     return e&f != 0 
     // ถ้า f คือ 0001 จะ return false เพราะ 1100 & 0001 = 0000
     // ถ้า f คือ 0100 จะ return true  เพราะ 1100 & 0100 = 0100
}

จากนั้นเรามาแก้ให้ echoHello เรารับ EchoFlag และใช้ has() เพื่อเช็ค flag ของ input

func echoHello(flags EchoFlag) {
    if flags.has(EchoEN) {
        fmt.Println("Hello")
    }
    if flags.has(EchoTH) {
        fmt.Println("สวัสดี")
    }
    if flags.has(EchoJP) {
        fmt.Println("こんにちは")
    }
    if flags.has(EchoFR) {
        fmt.Println("Bonjour")
    }
}

เสร็จหมดแล้ว! 🎊 🎉

ตัวอย่าง ใน Playground

แล้วมันเอาไว้ใช้ทำอะไร?

อย่างที่ยกตัวอย่างไปตั้งแต่แรก Native package ของ Golang อย่าง os จะใช้ Flag ในการทำ operation ต่างๆ โดยเฉพาะ arguments ที่จะส่งไปหาระบบปฏิบัติการ

หรือ package log ที่ใช้ flag ในการ set output option ของการ log

นอกจากนี้ผมก็ไม่รู้เหมือนกันว่าเอาไว้ทำอะไรอีก 🤨

จบสวัสดี 🙆‍♂️

ใช้งาน Interface แบบพิลึกของ Golang

Rungsikorn Rungsikavanich — Sat, 21 Nov 2020 07:38:25 +0000

บทความนี้ อ้างอิงแนวคิดจาก Effective Go และ Go CodeReviews เป็นหลัก

บทความนี้ต้องการความเข้าใจเกี่ยวกับสาเหตุ หรือเหตุผลของการใช้ Interface ในการเขียนโปรแกรม เบื้องต้นก่อน

⚡️ ชิงสรุปก่อนเลย TL:DR

Golang มี interface ที่ทำงานได้ยืดหยุ่นกว่า interface ภาษา OOP ทั่วไป โดยไม่ต้องมีการประกาศ implements และ Golang จะไม่นิยมประกาศ interface ไว้ที่ Library ต้นทาง แต่จะประกาศ Interface ไว้ที่ implementation ที่ใช้งานแทน โดยวิธีนี้ ทำให้การเขียน code สะอาดขึ้น และ Unit test ได้ง่ายขึ้น

👶 เรื่อง Interface คร่าวๆ

พูดถึงเรื่อง Interface กันหน่อยดีกว่า อย่างที่เรารู้กันว่า Interface กับภาษา Strong type เป็นของคู่กันมาตั้งแต่ไหนแต่ไร เพื่อให้ Programmer สามารถกำหนด Abstraction ของส่วนประกอบต่างๆภายในโปรเจคได้

ภาษา OOP อย่างที่เราคุ้นเคยกัน เช่น Java หรือ C# เนี้ย Interface แทบจะเป็นหัวใจหลักของการออกแบบระบบที่ซับซ้อน แทบจะขาดกันไม่ได้เลยทีเดียว เพราะหลายๆ Design Pattern ต้องการใช้ความสามารถของ Interface เพื่อทำให้บรรลุเป้าหมายได้

Interface ใน OOP 🐣

ก่อนที่จะเข้าเรื่อง Interface ของ Golang เรามาดูหน้าตาของ Interface ทั่วไปที่ใช้กันใน OOP language ก่อนซิ


public interface UserRepository { 
    void save(User user);
}

public class MySQLUserRepository implements UserRepository {
    public void save(User user) { 
         // doing convert User entity to SQL statement and
         // execute SQL statement
    }
}

public class BufferUserRepository implements UserRepository{
    public void save(User user) { 
         // doing in-memory buffering user stuff....
    }
}

จากตัวอย่าง snippet ด้านบน จะทำให้เราสามารถเลือกใช้ UserRepository อันใดอันนึงได้ โดยไม่ต้องยึดติดกับ implementation ของ class ใด class หนึ่ง โดยมีประโยชน์ในการทำ Unit test หรือการ Mocking test ใน package อื่นๆที่มี UserRepository เป็น dependency

ตัวอย่าง เช่น


// 🙅‍♂️ อย่าหาทำ การเพิ่ม Dependency แบบ Concrete ( ไม่ใช่ทุกกรณี )
public class LoginUseCase {
    public LoginUseCase(MySQLUserRepository userRepository){
        // do initialize stuff
    }
}

// 🙆‍♂️ ควรทำแบบนี้ มี dependency เป็น interface หรือ abstract class
public class LoginUseCase {
    public LoginUseCase(UserRepository userRepository){
        // do initialize stuff
    }
}

🐭 เข้าเรื่อง Interface ของ Golang

ใน Golang นั้นมันดันไม่ใช้ 100% OOP ซะทีเดียว อย่างเช่นภายใน Golang เราไม่มี Class และไม่มีการ ประกาศ Extends หรือ Implements

ผู้เขียนปวดกะบาลมาก สมัยเริ่มศึกษา Golang ใหม่ๆ

ถึงแม้ว่า OOP concept จะไม่ได้ถูกยกมาเต็มๆภายใน Golang แต่หลายๆ Idea ของ OOP ก็เป็นประโยชน์มากๆในการพัฒนา Software ด้วยภาษา Golang

เรามาเริ่มกันที่สิ่งที่ OOP มีแต่ Golang 🚫 ไม่มีกันก่อนซิ

ไม่มี abstract class
ไม่มี class ( มี struct แทนซึ่งเกือบๆจะเหมือน class แหล่ะแต่ไม่มี constructor )
ไม่มี Extends
ไม่มี Implements
interface ไม่มี Attribute ( Member Variable ) มีแต่ Method
ไม่มี Generic Type ( ปัจจุบัน version 1.14 ยังไม่มี จะมีใน 1.18 )

✅ แล้วสิ่งที่เหมือนกันหล่ะ

มี interface ( ก็แน่ซิวะ )
มีการทำ Encapsulation

อย่างที่รู้กันว่า Golang เป็นภาษาที่โง่เง่าแทบจะใกล้เคียง C++ โดยที่ Feature ต่างๆที่คุ้นเคยใน Modern programming langauge นั้นมันแทบจะไม่เอามาเลย เพราะฉะนั้นการใช้ interface ใน Golang มันก็เลยแสนจะเรียบง่ายแบบนี้

package main
type User struct { }
type UserRepository interface {
     Save(user User) error
}

type MySQLUserRepository struct { }
func (m *MySQLUserRepository) Save(user User) error { 
    // doing convert User entity to SQL statement and
    // execute SQL statement
}

จบแล้ว!? จาก snippet ถ้าผู้อ่านมาจากพื้นฐานการใช้ interface ภาษาอื่นก็อาจจะ มึนๆว่า

แล้วมันไป implements กันตอนไหนวะ?

ความพิเศษของ Interface ใน Golang ถูกเขียนไว้ในบทความ Effective Go ว่า

a way to specify the behavior of an object: if something can do this, then it can be used here.

ห้ะ อะไรทำตามนี้ได้ ก็เอามาใส่ตรงนี้ได้ 🤨

if something can do this, then it can be used here.

แน่นวลว่า ในภาษา Strong Type OOP อย่าง Java ไม่อนุญาติให้เรา assign class ที่ไม่ได้ implements interface ที่ถูกต้องเข้าไปใน Variable ของ interface นั้น

ถึงแม้ว่ามันทำงานได้ตรงตาม Behavior ที่ประกาศไว้ใน interface เป้ะๆ ก็ตาม

อย่างเช่น

package com.company;

class User {}

interface UserRepository {
    void Save(User user);
}

class MySQLUserRepository {
    public void Save(User user) { }
}

public class Main {
    public static void main(String[] args) {
        UserRepository userrepo = new MySQLUserRepository();
        // ^^^^ java: incompatible types: com.company.MySQLUserRepository cannot be converted to com.company.UserRepository
    }
}

วิธีการแก้อันนี้ก็คือ ตัว MySQLUserRepository จะต้อง Explicit ประกาศการ implements ของ UserRepository ด้วยถึงสามารถ Compile ผ่าน

class MySQLUserRepository implements UserRepository {
    public void Save(User user) { }
}

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

ผลลัพธ์ก็คือ ไม่จำเป็นจะต้องมี syntax implements ใดๆใน type declaration หาก type นั้นสามารถทำงานได้ตรงกับที่ interface กล่าวไว้ ถือว่าใช้ได้ สามผ่าน!!!!

package main
type User struct { }
type UserRepository interface {
     Save(user User) error
}

type MySQLUserRepository struct { }
func (m *MySQLUserRepository) Save(user User) error { }

func main() {
    var userrepo UserRepository
    userrepo = &MySQLUserRepository {} 
    // ^^^^^^^ บรรทัดนี้ใช้งานได้เลย ผ่าน เพราะ MySQLUserRepository สามารถ Save(user User) error ได้
}

เมื่อมีความยืดหยุ่นขนาดนี้ ทำให้ interface ใน Golang มันสามารถตีลังกาใช้งานได้หลายแบบ ตามความเหมาะสมของ design pattern หรือ ปัญหาต่างๆที่เราพยายามจะควบคุมอยู่

เนื้อหาต่อไปจะเป็นวิธีการใช้งานส่วนหนึ่งที่ผู้เขียนใช้งานอยู่

1. ประกาศ interface บริเวณที่ต้องการมี Dependency

ตามที่ Go CodeReviewComments ได้กล่าวไว้ในหัวข้อ Interfaces ว่า

Go interfaces generally belong in the package that uses values of the interface type, not the package that implements those values. The implementing package should return concrete (usually pointer or struct) types: that way, new methods can be added to implementations without requiring extensive refactoring.

แปล

Go interface ปกติแล้วจะต้องอยู่ใน package ที่ใช้งาน interface นั้น, ไม่ใช่ package ที่ implements สิ่งนั้นๆ. package ที่ implement ควรจะต้อง return concrete types ซึ่งวิธีนี้ จะสามารถทำให้เพิ่ม method ใหม่ๆได้ง่ายโดยไม่ต้องใช้เวลาในการ refactoring มาก.

หัวข้อนี้น่าจะเป็น หัวใจของการใช้ interface ของ Golang เลยทีเดียว ในปกติแล้ว ภาษา OOP จะมี interface ควบคู่กับ implementation ตลอดเพื่อให้รู้ว่า package นั้นจะมีอะไรให้ใช้งานบ้าง แต่ใน Golang จะพยายามทำกลับด้านกัน

package auth // login.go
type UserFinder interface { // นี่คือส่ิงที่เราต้องการ มีแค่ Find ก็พอแล้ว
    Find(context.Context, id string) (*entity.User, error)
}
type LoginUseCase struct { 
    Userfinder UserFinder
}
func (l *LoginUseCase) Login(ctx context.Context, id, pass string) (string,error) { 
    ...
    l.userfinder.Find(ctx, id)
}

package repo // user.go
type UserRepository struct {} // UserRepository เป็น implementation เต็มๆ
func (u *UserRepository) Find(context.Context, id string) (*entity.User, error) { }
func (u *UserRepository) Save(context.Context, user *entity.User) error { }

package main // main.go

func main() {
   var userrepo = repo.UserRepository{ } 
   var loginuc = auth.LoginUseCase{ 
        UserFinder: userrepo, // สามารถใช้ได้เพราะ มี Find()
   }
}

จาก Snippet จะพบว่า สิ่งที่ LoginUseCase ต้องการนั้นไม่ใช่ UserRepository แต่เป็นอะไรก็ได้ที่มี

   Find(context.Context, id string) (*entity.User, error)

ตามที่กล่าวไว้ใน UserFinder

และเนื่องจาก UserRepository นั้นมี method นี้อยู่ จีึงสามารถ assign ให้กับ LoginUseCase ได้

ดังนั้นสิ่งที่เกิดขึ้นคือ LoginUseCase นั้นไม่จำเป็นต้องรับรู้ว่ามี UserRepository หรือเปล่า โดย LoginUseCase แค่ประกาศสิ่งที่ต้องใช้งานไว้ที่ตัวเอง และรอ package อื่นๆเป็นคนโยนเข้ามาให้

2. ประกาศ Getter interface เพื่อทำ Union Type

จาก การใช้งานข้อ 1. ทำให้เราสามารถรวม 2 Type (หรือมากกว่า) เป็น Type เดียวกันได้ ในกรณีต้องการรับ parameter ให้ได้มากกว่า 1 type ยกตัวอย่างเช่น

package main
type Cat struct { 
    Name string
    Whiskers int32
} 
type Dog struct {
    Name string
    Fangs int32
}

func SpellName(c ???) { fmt.Println(c.Name) }

func main() { 
    SpellName(Cat{ Name: "Happies", Whiskers: 42 })
    SpellName(Dog{ Name: "Howard", Fangs: 4 })
}

ปัญหานี้ เกิดจาก Golang นั้นไม่มี Attribute ที่เป็น Value ใน interface และไม่สามารถทำ Union Type แบบภาษาอื่นๆได้ ทำให้ต้องมีการทำ Get เพื่อทำให้ 2 types สามารถ compat กันได้ (หรือสามารถทำ type assertion ได้ ซึ่งจะเล่าในบทความอื่น)

package main
type Cat struct { 
    Name string
    Whiskers int32
} 
func (c Cat) GetName() string { return c.Name } 
type Dog struct {
    Name string
    Fangs int32
}
func (d Dog) GetName() string { return d.Name }

func SpellName(c interface{ GetName() string }) { 
     //           ^^^^^ ตรงนี้ bonus การทำ inline interface
     fmt.Println(c.GetName()) 
}

func main() { 
    SpellName(Cat{ Name: "Happies", Whiskers: 42 })
    SpellName(Dog{ Name: "Howard", Fangs: 4 })
}

3. ประกาศ interface ควบคู่กับ struct ที่ package ไปเลย

ข้อนี้อาจจะขัดใจ Gopher ทั้งหลายอยู่บ้าง เพราะนี่คือการใช้งาน interface แบบ ภาษา OOP ทั่วไปคือการประกาศ interface ไว้ที่ package ต้นทาง เช่น

package repo // user.go

// **ต้องคิดดีๆก่อนเอา interface นี้ไปใช้
type UserRepository interface { 
    Find(context.Context, id string) (*entity.User, error)
    Save(context.Context, user *entity.User) error
}
type SQLUserRepository struct {} // UserRepository เป็น implementation เต็มๆ
func (u *SQLUserRepository) Find(context.Context, id string) (*entity.User, error) { }
func (u *SQLUserRepository) Save(context.Context, user *entity.User) error { }

เนื่องจากการประกาศ interface จะทำให้รู้ overview คร่าวๆของ สิ่งที่ package นี้ provide ออกมา ทำให้การ maintain struct ใหญ่ๆจะง่ายขึ้น ผู้เขียน บางคร้ังมีการประกาศ interface ไว้เพื่อควบคุม signature ของ concrete ที่ package นี้รับผิดชอบอยู่

แต่ในตัวอย่างนั้น UserRepository จะแทบไม่ได้ถูกใช้งานโดย package อื่นเนื่องจาก ขนาดของ interface นี้จะเริ่มใหญ่ขึ้นตาม concrete ที่ implement ซึ่งจะขัดกับหลักการ interface segregation และทำให้ maintain ยาก

สรุป

อยู่ข้างบนสุดแล้ว หัวข้อ TR:DR

ขอให้มีความสุขกับการเขียนโค้ด!

เล่าเรื่องการจัดการทีม เพื่อทำงานแบบ Remote ใน 2 เดือนที่ผ่านมา

Rungsikorn Rungsikavanich — Sat, 13 Jun 2020 06:28:21 +0000

TL;DR

ใช้ Communication tools ที่เหมาะสมกับการทำงาน (แนะนำให้ใช้ Workplace messaging แทน Social Messaging)

ควรมี Task Management ที่ทุกคนสามารถใช้งานได้ทั่วถึง

และ ทำ Peer Review ทั้งเชิง Technical และ Business ก่อน Deliver

เนื่องจากสถานะการแพร่ระบาดของเชื้อไวรัส COVID-19 ภายใต้บริษัทที่ผมทำงานอยู่จึงออกมาตราการให้ทุกคนทำงานจากที่บ้านถ้าหากเป็นไปได้

ตัดภาพมาที่ทีมที่ผมดูแลอยู่มี Developer จำนวน 6 คนและ Application ที่อยู่ในช่วง Development 1 โปรเจค ประกอบด้วย ชาวต่างชาติ 4 คนและคนไทย 2 คนและ

ทุกคนไม่เคยมีประสบการณ์ Remotely Working มาก่อน 😱

ความท้าทายของการทำงานแบบ Remotely Working คือการควบคุมขั้นตอนการทำงาน และการสื่อสาร

เนื่องจากโดยส่วนตัวแล้ว ผมเองไม่คิดว่าการทำงานแบบ Remotely หรือ Work From Home จะมีประสิทธิภาพดีกว่าการทำงานแบบ Face To Face ได้ในแง่ของการสื่อสาร

แต่ด้วยสถานะการบังคับ เราเลยต้องมีการวางแผนและออกแบบวิธีการทำงาน เพื่อให้ได้ประสิทธิภาพการทำงานเท่าเดิม (หรือดีกว่า) ให้ได้

ผมแบ่งหัวข้อในการออกแบบวิธีการทำงานของทีมเป็น

การสื่อสาร - Communication
การติดตามความคืบหน้า - Tracking
การตรวจสอบคุณภาพงาน และส่งงาน - Peer Review and Deliver

🌏 1. การสื่อสาร - Communication

เราคงจะเถียงไม่ได้ว่า การเดินไปจิกงาน หรืออธิบายรายละเอียดของงานนั้น ทำได้ง่ายกว่าในกรณี Face To Face แต่เมื่อเราต้อง Remotely Working สิ่งสำคัญอันดับแรกก็คือ

Communication Tools

Party ที่สำคัญหลักๆในการพัฒนาซอฟแวร์ไม่ได้มีเพียงแค่ Developer อย่างเดียว

เพราะยังรวมถึง Business Analysis team, Business Unit team, Management team, Test team ซึ่งทั้งหมดควรมี Protocol ในการสื่อสารเหมือนกัน

ภายใต้กลุ่มบริษัทของผม เราใช้ Microsoft 365 เป็นหลักในการทำงาน ดังนั้น Policy ของบริษัทจึงแนะนำให้ใช้ Microsoft Teams

(สามารถเป็น อะไรก็ได้เช่น Slack, Hipchat, Facebook Workplace)

ก่อนหน้านี้ ทุกคนสามารถใช้ Line ในการสื่อสารได้เพราะว่า การสื่อสารเป็นแค่การ สื่อความเล็กๆน้อยๆไม่ซับซ้อน

แต่หลังจากที่ต้องทำงานแบบ 100% Remotely เราพบว่า Line ไม่สามารถตอบสนองความซับซ้อนของการสนทนาในหลายแง่เช่น

การแยกบทสนทนาเป็นรายหัวข้อ ( การทำ Thread และ Post )
การจัดการ Channel, Chatroom เครื่องมืออย่าง Slack และ MSTeam ทำได้ดีกว่า Social Messaging ทั่วไป
การ Integrate เข้ากับ Cloud หรือ Storage ภายใต้ Microsft Office นั้น MS Team สามารถทำได้ดีกว่า Line มาก ในการแชร์เอกสารร่วมกัน
การประชุมสาย MS Team สามารถทำได้ดีกว่า Line และสามารถ Record การสนทนาได้ และสามารถนัดประชุมล่วงหน้าได้ (ใช้ร่วมกันกับ Outlook Calendar)

Protocol ของการสื่อสาร

ภายใต้หัวข้อนี้จะพูดถึงการใช้งาน Microsoft Team เป็นหลัก

การใช้ Channel

ภายใต้ feature ของ Microsoft Team เราสามารถจัดการหัวข้อการสนทนาได้อย่างละเอียดกว่า Social Messaging ทั่วไปโดยภายใต้ทีมของผม เราใช้ Channel ในการสนทนาเชิงวิเคราะห์ต่างๆเช่น วิเคราะห์ Requirement, รายงานปัญหาที่เกิดจาก Release ต่างๆ

ภายใต้ Channel มีการทำ Annoncement และการ Posts

การใช้ Chat และ Group Chat

เนื่องจาก MS Team นั้นมี Feature การสนทนาค่อนข้างแตกต่างจาก Line และ Social Messaging ทั่วไป ชนิดของบทสนทนานั้นแบ่งออกเป็น

Channel
Post, Annoucement
Meeting Chat
Chat and Group Chat

ทั้งสามอย่างมีวิธีการใช้แตกต่างกันตามแต่ละทีมจะนำไปประยุกต์ใช้และเราใช้ Chat และ Group Chat กับการสนทนาประจำวัน

มีการรายงานสถานะประจำวันของแต่ละคน Daily Meeting

ทางทีมยังคงใช้รูปแบบการทำงานที่ชื่อว่า Agile อยู่ เรายังมีการทำ Remotely Daily Meeting ทุกวันในช่วงเวลาที่ทุกคนสะดวก ( 11:00am ) เพื่อให้ทุกคนสามารถรายงานความคืบหน้าและสถานะการของตัวเอง (เฉลี่ย ไม่ควรเกิน 20 นาทีต่อครั้ง)

หัวข้อของ Daily Meeting ประกอบด้วย

เมื่อวานนี้ทำอะไร
วันนี้ทำอะไร
ต้องการให้ใครช่วย

ทำเอกสารให้มันใช้งานได้จริงๆ

หลังจาก Work From Home เราเน้นเรื่องเอกสารมากขึ้น ในการทำงานแต่ละ Issues

ยกตัวอย่างเช่น การทำ Merge Request จะต้องมี Template ของการทำ MR ชัดเจนเพื่อให้การทำ Peer Review ทำได้สะดวก

อื่นๆ

เราใช้ Gitlab และการทำ Merge Request เพื่อทำ Peer review
เราออกแบบ Git branching strategy ร่วมกันเพื่อให้การทำงานทุกคนไปในทิศทางเดียวกัน

ปัญหาที่เจอในการสื่อสาร

สมาชิกทีมบางส่วนยังคุ้นเคยกับการใช้งาน Line มากกว่า เนื่องจาก Microsft Team ไม่ใช่ Social Messaging จึงมีขั้นตอนการใช้งานยุ่งยากมากกว่า Line ที่ออกแบบมาเพื่อการใช้งานอย่างเรียบง่าย การ Adopt ใช้ Microsoft Team ต้องมีการเรียนรู้เพิ่มเติมจาก เอกสารต่างๆหรือ Training Session เพื่อให้ใช้งานได้อย่างมีประสิทธิภาพ ทำให้บางส่วนของ Team ยังมีการใช้ Line ในการสื่อสารอยู่
ปัญหา Internet Connection และ คุณภาพของ Microphone เนื่องจากทุกคนไม่คิดว่าการทำงานแบบ Remotely จะยืดยาวจึงไม่ได้มีการเตรียมพร้อมหา Internet Connection ที่พร้อมสำหรับการใช้งาน รวมถึงอุปกรณ์การสื่อสารต่างๆเช่น คุณภาพของ Microphone
กำแพงด้านภาษา เนื่องจากภายในทีมมีชาวต่างชาติ การสื่อสารบางอย่างค่อนข้างติดขัดบ้าง เพราะว่าภายในทีมบางส่วนไม่คุ้นเคยกับการใช้ภาษาอังกฤษในการทำงาน
ความขี้เกียจเขียนเอกสารของ Developer

🧑🏼‍💻 2. การติดตามความคืบหน้า - Tracking

อย่างที่กล่าวไปเบื้องต้นแล้วว่าเราใช้ Agile ในการทำงาน การสื่อสาร Tools ที่ทางบริษัทมีให้ใช้คือ Atlassian JIRA

เนื่องจาก Position ผมเองเป็น Technical Lead และ Scrum Master ไปในตัว เราจึงเป็นคนที่ควบคุมกระบวนการ การทำงานของทีมไปด้วย

โชคดีของเราคือ Test team มีการใช้งาน JIRA ร่วมกัน ทำให้การทำ Bug tracking นั้นสะดวกมากยิ่งขึ้น (ปกติทาง Test team ใช้ HPQC แต่ช่วยมาทำใน JIRA ให้ด้วย)

ทำให้เราสามารถ tracking งานต่างๆ และเห็นภาพรวมของโปรเจคได้ชัดเจน

เนื่องจากการใช้ JIRA และทำ Issue Tracking เรามีการปฏิบัติอยู่แล้วตั้งแต่ก่อน Work From Home จึงไม่มีอะไรกระทบมากนัก

Draft Release note ให้ชัดเจน

Release Note เป็นส่วนหนึ่งที่มีประโยชน์มากในการวางแผนการพัฒนาซอฟแวร์

การทำ Release Note ที่ดี จะทำให้เราสามารถกำหนดและสื่อสารสิ่งที่จะ Deliver มาได้ชัดเจน ให้กับลูกค้าหรือ ทีมอื่นๆที่จะต้องเข้ามามีส่วนร่วมในการพัฒนาซอฟแวร์

ปัญหาที่เจอ

ในฐานะคนดูแล Sprint และ Technical ไปพร้อมกัน ทำให้บางครั้ง ข้อมูลต่างๆภายใน JIRA ไม่ได้ถูกอัพเดทตามต่อวัน
Notification ใน JIRA เมื่อเกิด Activity ต่างๆ (เวอร์ชั่นเก่า) ยังไม่ดีเท่าที่พอใจ บางครั้งทำให้การ Response Issue ต่างๆใน JIRA ค่อนข้างช้า
Integration ระหว่าง Gitlab กับ JIRA ทำได้ยาก เนื่องจากข้ามผลิตภัณฑ์กัน จึงไม่ Seemless เท่าที่ควร (ถ้าเป็น BitBucket จะสามารถ Integrate JIRA task เข้ากับ Merge Request ได้ง่ายกว่า)

🤖 📦 การตรวจสอบคุณภาพงาน และส่งงาน - Peer Review and Deliver

เนื่องจากซอฟแวร์ที่ดูแล มีขั้นตอนการทำงานในเชิงธุรกิจ ( Business logic and Functionality ) ที่ค่อนข้างซับซ้อนและครอบคลุมหลายผลิตภัณฑ์ในด้านการเงิน

ทำให้การส่งงาน ( Merge code ) จำเป็นต้องมีการ Review จากหลายส่วน เพื่อให้รองรับการดูแลรักษาในอนาคต (Maintainability)

จึงต้องมีการทำ Policy ต่างๆขึ้นมาเพื่อรองรับการทำงาน เช่น

การส่งงานใน Merge Request ต้องครอบคลุมถึงการเขียน Test ที่สำคัญใน Merge Request Change นั้นๆ
Convention ของการเขียนโค้ด (Code Style and Convention Guideline)
Template ของการเปิด Merge Request
Branching Strategy และการ Merge Request เข้า release branch ให้ถูกต้อง
ทำ Technical Peer Review
CI/CD เพื่อรัน Unit-test, Integration-test และ E2E-test

เรายังมีการจัด Business Functionality Review Session เพื่อให้ Business Team ได้เข้ามามีส่วนร่วมในการ Review ชิ้นงานแต่ละ Feature ก่อน Merge เข้า Stable Branch

สรุป

เขียนมาถึงตรงนี้ก็หมดแรงแล้ว ถึงอย่างไรบทความข้างต้นเป็นการออกแบบการทำงานเพื่อรองรับกับทีมที่ผมเป็นคนดูแลอยู่

สุดท้ายแล้วการทำงานจะเป็นแบบไหนขึ้นอยู่กับลักษณะเฉพาะของงาน และทีมที่เราทำงานอยู่ด้วย

การทำให้ทีมทำงานได้อย่างมีประสิทธิภาพ ต้องอาศัยการทำความเข้าใจคนภายในทีม รูปแบบการทำงาน นิสัย ทัศนคติ เพื่อนำมาออกแบบวิธีการทำงานให้เกิดประสิทธิภาพสูงสุด

Forem: Rungsikorn Rungsikavanich

ใช้ node module 2 version ใน project เดียวกัน

Reference

STOP USING window as any

TLDR;

Why?

Here come the window as any

Bring back the type

How to proper use ambient enum from Definition file

Why?

How to properly solve it?

const enum solution (Not recommended)

Declare ambient value in global scope (Recommended)

Consistent

Inconsistent

Summary

Terra Network SmartContract Migration

มีอะไรเปลี่ยนไปบ้าง?

Support On-chain Contract Migration

วิธี binding Entrypoint เปลี่ยนใหม่

Extern API เปลี่ยนเป็น Deps และ DepsMut

ตัวอย่าง

เพิ่ม Arguments ให้กับ Contract entry point ( init, handle, migrate )

ตัวอย่าง

Migrate Response, HandleResponse, InitResponse กลายเป็น Response เฉยๆ และเป็น non_exhaustive

Log API เปลี่ยนชื่อเป็น Attribute

HumanAddr ถูก Deprecated

Project Layout ของ Golang EP.1

✨ TL;DR อีกแล้ว

Project Layout คืออะไร?

Dependencies and Project Information

Implementation

1. cmd Folder

2. internal Folder

3. pkg Folder ( หรืออยู่ที่ root ไปเลย )

4. web Folder

Reference

10110 การทำ Flag ด้วย Bitset ใน Golang

🌟 TL;DR สรุปก่อนไปเลย

Flag คืออะไร

Bitwise Operator คืออะไร?

Left shift operator

AND และ OR operator

สร้าง Enum ด้วยค่าของ bit set

ใช้ iota และ เปลี่ยนจาก int เป็น type ใหม่เพื่อให้ bitset ใช้งานง่ายขึ้น

แล้วมันเอาไว้ใช้ทำอะไร?

ใช้งาน Interface แบบพิลึกของ Golang

⚡️ ชิงสรุปก่อนเลย TL:DR

👶 เรื่อง Interface คร่าวๆ

Interface ใน OOP 🐣

🐭 เข้าเรื่อง Interface ของ Golang

เรามาเริ่มกันที่สิ่งที่ OOP มีแต่ Golang 🚫 ไม่มีกันก่อนซิ

✅ แล้วสิ่งที่เหมือนกันหล่ะ

if something can do this, then it can be used here.

1. ประกาศ interface บริเวณที่ต้องการมี Dependency

แปล

2. ประกาศ Getter interface เพื่อทำ Union Type

3. ประกาศ interface ควบคู่กับ struct ที่ package ไปเลย

สรุป

เล่าเรื่องการจัดการทีม เพื่อทำงานแบบ Remote ใน 2 เดือนที่ผ่านมา

TL;DR

ผมแบ่งหัวข้อในการออกแบบวิธีการทำงานของทีมเป็น

🌏 1. การสื่อสาร - Communication

Protocol ของการสื่อสาร

การใช้ Channel

การใช้ Chat และ Group Chat

มีการรายงานสถานะประจำวันของแต่ละคน Daily Meeting

หัวข้อของ Daily Meeting ประกอบด้วย

ทำเอกสารให้มันใช้งานได้จริงๆ

อื่นๆ

ปัญหาที่เจอในการสื่อสาร

🧑🏼‍💻 2. การติดตามความคืบหน้า - Tracking

Draft Release note ให้ชัดเจน

ปัญหาที่เจอ

🤖 📦 การตรวจสอบคุณภาพงาน และส่งงาน - Peer Review and Deliver

สรุป

Here come the `window as any`

`const enum` solution (Not recommended)

ใช้ `iota` และ เปลี่ยนจาก int เป็น type ใหม่เพื่อให้ bitset ใช้งานง่ายขึ้น