โลกนี้ไม่มีอะไรแน่นอน…

ผมทำ software มา 5–6 ปี ในโลก software development ที่ทุกอย่างเปลี่ยนตลอดเวลา ทำๆ ไปเจออะไรก็ไม่รู้ ยิ่งไม่แน่นอน

ตลอดเวลาที่ทำงานมา อยู่ใน agile environment ตลอดมามักจะมีความรู้สึกเหล่านี้

• estimate ไปทำไม เดี๋ยวก็ผิดอยู่ดี
• ไหนบอก story points, t-shirt sizing เป็นแค่ relative sizing ไม่เกี่ยวกับ effort แต่สุดท้ายก็เอาไปคิดแลข ไปทำ burn up/down chart วัด velocity วาง timeline อยู่ดี

เคยทำงานแบบไม่ estimate เลย เดี๋ยวก็จะต้องมี party อื่นที่ต้องพึ่งเรา มาถามเราอยู่ดี จะตอบส่งๆ ไปแบบไม่คิด เดี๋ยวอาจจะทำเราลำบากทีหลังอีก

ลึกๆ ในใจก็คิดว่า ถ้าอธิบายอนาคตได้บ้าง เท่าที่ความรู้มี ก็คงจะดี จะได้วางแผนได้รัดกุมมากขึ้น

ไปเจอหนังสือเล่มนึงที่ผมชอบมาก ชื่อว่า “How to measure anything” เลยเอาสิ่งที่เรียนรู้จากหนังสือเล่มนี้ มาลองปรับใช้กับ development estimation

• ไม่มีอะไรแน่นอน เพราะฉะนั้นถ้าจะทำความเข้าใจมัน ต้องยอมรับมันก่อน
• ความรู้และประสบการณ์ของเราคือข้อมูล
• หากความไม่แน่นอนมีมากเกินไป จงแตกปัญหาออกมาเป็นชิ้นที่เล็กลง หรือหาข้อมูลเพิ่ม

ยอมรับความไม่แน่นอน

เวลาเราให้ตัวเลขไป 1 ตัว t-shirt ไป 1 size เอาไปแปลเป็นเวลาที่ใช้ เอามาบวกกัน เพื่อบอกเวลาที่จะใช้ทั้งหมด ก็เหมือนกับหลอกตัวเอง เพราะจริงๆ แล้วเวลาเราบอกว่า 3 story points มันอาจจะแปลว่า 1 วันก็ได้ 5 วันก็ได้ แต่เราพอจะเดาได้ว่า เร็วที่สุด เร็วแค่ไหน ช้าที่สุด ช้าแค่ไหน แบบไม่ surprise มากๆๆ จริงๆ

สมมติว่า การที่

“เราไม่ surprise มากๆๆ จริงๆ”

แปลให้ formal ได้ว่า

“เรามั่นใจ 90% ที่จะทำงานชิ้นนี้เสร็จเร็วสุดภายใน 1 วัน ช้าสุดภายใน 5 วัน”

โดย assume ว่า การกระจายตัวของข้อมูลจะเป็น normal distribution

ทีนี้เราก็มีข้อมูลทั้ง “มันน่าจะเสร็จเมื่อไหร่” และ “มั่นใจแค่ไหน” ที่เอามาใช้ในการคำนวณได้แล้ว

ก่อนจะไปต่อ คนเรามักจะ underestimate (หรือบางคนก็ overestimate) สิ่งที่อยู่ตรงหน้า เพราะฉะนั้น เวลาจะ estimate ควรจะ calibrate ผู้ให้ข้อมูลด้วย เช่น

ถ้าให้เลือกพนัน 1 BTC บนเกม 2 เกม

1. ถ้า estimate ถูก งานเสร็จภายใน 1–5 วัน คุณชนะ

2. ถ้ามี lottery 100 ใบ 90 ใบในนั้นจะทำให้คุณชนะ ที่เหลือจะทำให้คุณแพ้

ถ้าชนะ จะได้ 1 BTC แพ้เสีย 1 BTC คุณจะเล่นเกมไหน?

ลองคิดตามดูนะครับ

…

…

คำตอบคือ ต้องรู้สึกไม่ต่างกัน เล่นเกมไหนก็ได้ ทั้งสองเกมควรมีความน่าจะเป็นที่จะชนะเท่ากัน คือ 90%

ถ้าเลือกเกม 1 แปลว่า คุณ overestimate งาน เพราะคุณเชื่อว่า ช่วงความมั่นใจที่ estimate มันกว้างกว่า 90% ยังไงงานก็มีโอกาสทำเสร็จในช่วงมากกว่า

ถ้าเลือกเกม 2แปลว่า คุณ underestimate งาน เพราะคุณเชื่อว่า ช่วงความมั่นใจที่ estimate มันแคบกว่า 90% เล่น lottery มีโอกาสชนะเยอะกว่า

แล้วก็ปรับการ estimate กันไป ฝึกให้ทีมชินกับ concept นี้ แล้วเราก็จะได้ข้อมูลในการคาดการณ์อนาคตที่แม่นยำขึ้น

ความไม่แน่นอนมีมากเกินไป

1–3 วัน กับ 3–20 วัน นั้นต่างกันอย่างเห็นได้ชัด ความไม่แน่ใจของผู้ให้ข้อมูลถูกแสดงออกมาเป็นตัวเลข ซึ่งจะส่งผลต่อความไม่แน่นอนของการพยากรณ์ในที่สุด

เราทำอะไรได้บ้าง?

1. แตกปัญหาให้เล็กลง แล้วลอง estimate ใหม่ ปัญหาที่เล็กลง เราจะเข้าใจมันได้ดีมากขึ้น
2. ใช้เวลาไปเก็บข้อมูลเพิ่มเติมเกี่ยวกับสิ่งที่ไม่แน่ใจ

รวบรวมผล

สุดท้าย เราอยากรู้ว่า ด้วยงานทั้งหมด เราจะใช้เวลาเท่าไหร่ แต่เราจะเอา upper bound มาบวกกันให้หมด เอา lower bound มาบวกกันให้หมด ก็ไม่ได้ เพราะจริงๆ แล้วตัวแปรที่เรามี เป็นตัวแปรแบบสุ่ม (random variable) ตัวเลขที่เราได้คือตัวแทนของ normal distribution

วิธีที่เราใช้รวมรวมผลทั้งหมดคือ monte carlo simulation

อธิบาย monte carlo simulation ง่ายๆ ก็คือ สมมติมี งานสามชิ้น

1. 1–4 วัน
2. 2–7 วัน
3. 4–5 วัน

เราจะเอา upper, lower bound มาหา normal distribution parameters

mean = (upper + lower) / 2
sd = (upper - lower) / 3.29

เมื่อได้ mean กับ sd แล้ว เราจะเอาไปใช้สุ่มใน program ต่างๆ ได้ เช่น ใน python

np.random.normal(mean, sd, 1000) # 1000 samples

สมมติ เราสุ่มหยิบรอบแรก ได้ (1.2, 3.3, 4.1) เวลาที่ใช้จากผลการสุ่มรอบแรกคือ 1.2 + 3.3 + 4.1 = 8.6 วันอย่างนี้เป็นต้น สุ่มไปหลายๆ ผลลัพธ์จะกระจายตัวเป็น normal distribution อีกครั้ง

ตัวอย่าง tool ที่เราใช้กันเองในทีม เราดึงข้อมูลมาจาก task management แล้วทำการคำนวณตามที่อธิบายไปข้างต้น ได้ผลลัพธ์หน้าตาแบบนี้

มีข้อมูลมากพอสามารถคำนวณ progress และ projection ของความมั่นใจว่างานจะเสร็จในช่วงเวลาไหนได้

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

พวกเรา █████ ทีมเรารักที่จะ experiment, ทำงานเกี่ยวกับ software development, cryptocurrency, blockchain เพราะงั้นเราต้องการคนที่พื้นฐานแข็งแรงมาจอยกัน เพราะทีมนี้อยากซิ่ง ไม่อยากทวนเรื่องพื้นฐานกันแล้ว

สนใจร่วมงานกัน หรืออยากคุยด้วยเฉยๆ มาพูดคุยกันใน discord ได้ที่นี่

Estimate งานยังไงให้แม่น? was originally published in █████ [REDACTED] .org on Medium, where people are continuing the conversation by highlighting and responding to this story.

After flashing firmware on GMMK pro for key mapping using binary produced from QMK Configurator, one might find rotary knob no longer works.

The reason being, the configurator does not have the functionality to handle rotary encoder. We need to build the firmware ourselves.

disclaimer: I am on macbook m1, so I used docker for the job since installing qmk cli locally does not work for me. If you want to thread down the path of installing the cli locally, please check this out.

Environment Setup

You need git and docker installed. If you are a software engineer, you probably already familiar with them, if you are not you need terminal console in order to interact with the following content.

Mac has default Terminal app,

On windows, this could get tricky. Using Linux Subsystem might be the best bet IMHO but I haven’t tested it myself.

For Linux users, I think you know what to do…

Getting Started

1. Let’s clone the qmk firmware repository and change directory into it.

git clone --recurse-submodules https://github.com/qmk/qmk_firmware.git && cd qmk_firmware

2. Download your already configured keymap json file and move it into qmk_firmware directory mentioned above. By default, the file name would be gmmk_pro_ansi_layout_mine.json

3. On the same terminal console, current directory as qmk_firmware, create directory to store new keymap, you can name it however you like instead of my_keymap_name

mkdir -p keyboards/gmmk/pro/ansi/keymaps/my_keymap_name

4. Convert json to C code for further modification

docker run --rm -it \
-w /qmk_firmware \
-v "$(pwd)":/qmk_firmware qmkfm/qmk_cli \
qmk json2c -o keyboards/gmmk/pro/ansi/keymaps/my_keymap_name/keymap.c gmmk_pro_ansi_layout_mine.json

5. Open the C file with your text editor of choice, any plaintext editor would work (not Words or Pages but TextEdit or Notepads). I use VScode for syntax highlighting but you don’t need to. Then add the following lines at the bottom:

bool encoder_update_user(uint8_t index, bool clockwise) {
    if (clockwise) {
      tap_code(KC_VOLU);
    } else {
      tap_code(KC_VOLD);
    }
    return true;
}

5. Now you can run the following command to build the firmware, which will output the file in qmk_firmware directory. This will take awhile. (it’s the same process as what you click compile in the configurator)

util/docker_build.sh gmmk/pro/ansi:my_keymap_name

6. The first time you flash the firmware, stock reset combination on your keyboard is <Space> + B but after the first time, it is potentially changed. If you have no idea what did you remap the reset command to, it would by default be fn + \

TS;WM

By default, there is the modifier MO(1) down here to go to layer 1

And on layer 1

The RESET is here

7. Go to your QMK Toolbox and open the file gmmk_pro_ansi_my_keymap_name.bin in the qmk_firmware directory. Then unplug your gmmk pro, hold Fn + \, plug the cable back and then flash the firmware.

It is quite a wild ride since it gets very technical, but for me, I just learned about the existence of QMK and I see that there are a lot I can do with it. I can make rotary on different layer behaves differently, for example. And I might do a tutorial for that in the next post.

Have fun typing.

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

หรือจริงๆ แล้วมันเป็นเพราะ dynamic ของคนในห้องรึเปล่านะที่ทำให้เกิดความรู้สึกว่า ปัญหาที่เราคิดว่าสำคัญไม่ได้ถูก address จริงๆ พูดกันแต่เรื่องอะไรก็ไม่รู้ เราเองก็ไม่อยากจะไปแย้งอะไรเขา กลัวชาวบ้านเค้าเสียเวลาเหมือนกัน

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

Insight

เวลาทำ product เค้ายังไปทำ user research เพื่อเก็บ insight มาออกแบบ product เลย ทำไม facilitator จะเก็บ insight มาออกแบบ retro บ้างไม่ได้ เคยเห็นท่าที่ใช้ทำ health checking โดยการถามว่า

สบายใจจะพูดแค่ไหน ให้คะแนน 1–5

แต่บางครั้ง เราตอบ 4 ตอบ 5 เราก็ไม่ค่อยจะพูดอยู่ดี หรือมิติมันน้อยเกินไปทำให้คน over-evaluated ความสบายใจของตัวเอง?

3 คำถาม

เลยนึกถึงคำถามที่เปิดให้ทีมได้มีโอกาส inspect ตัวเอง ก่อนที่จะไป inspect team เพราะถ้าตัวเองยังไม่รู้เลยว่าในใจเรามีอะไรบ้าง มัวแต่ไปโฟกัสเรื่องคนอื่นก็รังแต่จะกังวล ไม่กล้าพูดมากนักเสียเปล่าๆ การเปิดโอกาสให้ได้คิดถึงตัวเอง ทำให้คนกล้าที่จะพูดสิ่งที่ตัวเองคิดมากขึ้น

นอกจากนั้นยังเอา insight ที่ได้จากตัวเองมาลง pool of meaning ของ team แล้ว facilitator ก็สามารถนำสิ่งเหล่านี้ไปประกอบ discussion ต่อๆ ไปได้อีกต่างหาก

ถ้าต้องให้นึกถึงแค่เรื่องเดียวที่เราเชื่อว่าเป็นเป้าหมายสำคัญที่สุดสำหรับทีมในตอนนี้ ไม่มีใครตัดสินว่าสิ่งที่เราเชื่อมันถูกหรือผิด คุณนึกถึงเรื่องอะไร

คำถามนี้จะช่วย set tone ของ retrospective ว่าเราควรจะคุยเรื่องอะไรกันแน่ หลายๆ ครั้งจะเห็น pattern ว่าจริงๆ แล้วหลายคนแคร์เรื่องเดียวกัน แต่ไม่มีโอกาสได้พูดออกมาดังๆ เลยไม่ได้ align กัน

มีไอเดียบางอย่างที่ยังตั้งไข่อยู่ในหัว คิดว่าต้องเจ๋งแน่ๆ แต่ยังคิดไม่เสร็จ ไม่กล้าพูดออกไป สิ่งนั้นคืออะไร

คนเรามักจะ doubt ตัวเองว่าสิ่งที่พูดไปคนต้องไม่เข้าใจแน่ๆ logic ของเรายังไม่แข็งแรงพอ ถ้าเราไม่กล้าพูดถึงไอเดียพวกนี้ให้ทีมฟัง ก็พอจะเห็นได้ว่า psycological safety ในทีมยังมีไม่พอรึเปล่า ซึ่งผมเห็นว่าเป็นวิธีเข้าใจถึงความสบายใจของคนในทีมมากกว่าถามว่าสบายใจมากแค่ไหน แถมบางที แค่ตระหนักได้ว่ามีความกังวลนั้นอยู่ ก็อาจจะก้าวข้ามมันด้วยตัวเองได้ด้วยซ้ำ เพราะขั้นแรกของการแก้ปัญหา คือการตระหนักรู้ว่ามีปัญหา และ psycological safety ก็มักจะเป็นปัญหาที่คนไม่ค่อย recognize กันซักเท่าไหร่

นึกถึงเรื่องที่พลาดหรือเรื่องโง่ๆ ล่าสุดที่ทำลงไป จะเล็กน้อยแค่ไหนก็ได้ เรากล้าเล่ากลางห้องนี้มากแค่ไหน?

0 คือไม่กล้าเลย
1 คือพูดอ้อมๆ
2 คือยอมรับว่าพลาดอย่างเต็มอก

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

คำถามเหล่านี้ นอกจากจะทำให้เห็นถึง insight ของทีมแล้ว ยังช่วยเพิ่ม psychological safety ของคนในทีมอีกด้วย หลังอยากได้ insight มาแล้ว facilitator จะได้เห็นว่า จะ facilitate ต่อไปท่าไหนดี จะไป focus ที่ goal ที่ไม่ align, ที่ไอเดียที่อาจจะไปแก้ปัญหาที่ชัดแล้ว, psychological safety ของทีม, discussion ไหนสำคัญ ควรลงลึก discussion ไหนปล่อยไปคุยนอกรอบ

ลองเอาไปปรับใช้กันดูนะครับ หวังว่าจะทำให้ retrospective มีความหมายและมีประโยชน์มากขึ้น

เวิร์คไม่เวิร์คยังไงมาบอกด้วย!

I stumbled across this post, which contains a list of books claimed to be suggested by Andrew Ng. And I found this book interesting since I’m looking for ways to improve my teaching as well as improving my personal learning guide.

In this first part, by the time I wrote this, I have finished about half of the book (4 out out of 9 chapters) and here is what I have understood so far.

Thinking is hard, we tends to avoid it. How could we overcome this curse?

• Human tends to be curious, which could lead to thinking.
• When curiosity resolves, we feel pleasured.
• But curiosity is fragile, if content is exceeding cognitive limits we will give up.
• If the explanation is too exhaustive, we will not be curious. Which could be labeled as boring.

Trigger students curiosity, urging them to ponder about problem and let them solves, while respecting their cognitive limits helps them get the pleasure of solving problem.

Critical thinking requires background knowledge.

• Factual knowledge improves memory. Since having an idea about a certain subject reduce the burden of working memory and free up computing power for processing new information.
• Knowledge that should be instilled is the unifying idea in the subject that comes up over and over again. Since it will be retrieved to aids new learning effectively.
• Shallow knowledge is better than no knowledge.
• Knowledge must be meaningful. Unconnected fact and drilling leads to boredom rather than joy of discovery.

Teaching only facts, not skills has been a common complaints for ages, but in reality “factual knowledge precede skills”. So instilling important factual knowledge in a meaningful way improves critical thinking ability.

Thinking kept being mentioned since it’s an important steps to store information in long-term memory.

• Memory is the residue of thought.
• We memorize things in the aspect that we think about.
• Make student think about meaning, since it’s easier for later drawing connection thus easier to retrieve them from long-term memory.
• “The answer has never been interesting, but if you know the question, it might.”
• Attention grabbers might distract students’ thought, use it to point to the right direction and only when the students has enough background knowledge to process what’s happening.
• If some thing really has no meaning (eg. multiplication table) then use mnemonics.
• Design lesson to have story structure since it’s natural for student to draw connections.
• That does not mean it has to be story telling, but do whatever activity that eventually contains 4Cs.

Causality: Sense of connection

Character: Establishing perspective

Conflict: Main focus that requires to be resolved

Complications: Minor curiosity igniter that keeps attention

Using story structure to guide student to think about meaning of the subject. The context set for learning affect what students will remember since they remember what they think about.

It’s hard to understand abstract ideas.

• Concrete ideas are easier to grab since we already have some idea related to them.
• Abstract ideas comes from generalizing concrete idea, so gives more example around the same abstract idea.
• Ask student to compare the difference between example helps shaping abstract ideas since they will have to think about what are the shared properties as well.
• Metaphor works, since it draws connection with existing knowledge.

Abstract ideas could be shaped out of examples, let the student pondering about the differences to get over the “surface structure” and get the sense of “deep structure”. Making deep structure being spoken to emphasize their thinking rather than keep invoking thoughts about factual knowledge too much. And make realistic expectation, deep knowledge is hard but shallow knowledge is better than no knowledge at all.

So, this is what I have learned so far.

What do you think about it?

See you again in Part 2 (coming soon)

I’ve got a chance to walk through my trading card game kata with a bunch of passionate new grads in a personal boot camp run by Salah Chalermthai. The code is written in TypeScript but in a very functional manner. They asked me to point out some good resources about functional programming. So I compiled this list to aid their curiosity.

I would like to separate into 3 sections, Practical, Theoretical and Interesting Functional Languages. While practicality is important, understanding the underlying concept of things makes you better at reasoning about and utilize tools in your toolbox. Learning different languages that has different philosophy can change the way you think about programming. I will point out some languages with different flavors so you can explore.

Practical

Hello, Functional Programming!

Well, this has written by me. It’s a very brief introduction to the subject, just to get the sense of what it means.

SOLID: The Next Step is Functional

This one is about design principle that is widely known in OO community. SOLID has been discussed in the boot camp so I think it would be interesting to look at it from a functional lens.

Professor Frisby Introduces Composable Functional JavaScript

Functional programming tends to be discussed in a very abstract manner since it has a lot of useful composable abstractions at hand to be used to reason about and model things. This course is more example based, practical use case driven and when you see the pattern they will extract those patterns and form abstractions which can be reused further in many context.

F# for fun and profit

One of my favorite website about functional programming. The author use F# language as a medium to talk about lots of interesting concept in functional programming and how can they be useful in solving real business problem.

From Design Pattern to Category Theory

How do you design good abstractions? By using abstractions that already exist.

This series of blog posts talk about utilizing a branch of mathematics called Category Theory as design patterns. Category Theory has bunches of small and lawful, well defined abstractions which we can built upon. It’s a study of mathematical structures but turns out to be very useful in programming as well.

Theoretical

Lambda Calculus — Fundamentals of Lambda Calculus & Functional Programming in JavaScript

Lambda Calculus is a formal system for expressing computation which can simulate any Turing machine. It’s based on function abstraction and application which is the basic of functional paradigm.

Category Theory for Programmer

If you get hooked into Category Theory at some point and wants to understand more about what it actually means, this might be interesting for you. This will take you to have a deeper look into Category Theory and also map those ideas into Haskell (I also learn a bit of Haskell in the mean time).

There’s also a video version and pdf version.

Warning: this might be very abstract to some, it takes sometimes to digest. I would not recommend this for those who has just started functional programming but after awhile you will encounter those weird terms from Category Theory, so come here when you are really curious about it.

Interesting Functional Languages

Haskell

An advanced, purely functional programming language. It’s not a must learning Haskell to understand FP but if you want to really understand FP, you should give it a try.

Haskell resources:

• Learn You Haskell for Great Good!
• Haskell programming from first principles
• What I Wish I Knew When Learning Haskell

Clojure

While Haskell type system is static. Clojure is dynamic. Clojure takes different approach from Haskell which has a lot of higher level abstraction, Clojure only cares about few set of data structures and lots of functions to manipulate them.

Clojure resources:

• Clojure for brave and true

Elixir

Elixir has a friendly syntax like ruby with a lot of language features that aids functional paradigm. It runs on Erlang vm which is used for building highly concurrent system for telephone switches back in the days. Elixir can spawn a very lightweight process and send messages to each others which is a very nice building block for modelling concurrency.

I hope this is useful :)

Static method is bad, or at least, when it’s not pure.

Pure, in this context, means that:

• It causes no side-effects, mutates nothing outside of the method scope.
• It is referential transparent, meaning any reference must be passed as an argument or else mutation of your referenced value will results in non-deterministic result.

Why is that bad?

Because whoever consumes that impure static method will not be easy to test. If the static method is pure it might be fine since you can predict its behavior and you don’t need to mock them (less mocking is great!), just asserting the return value is enough. But the impure one, it’s a different story.

If the code is under your control, you can and should avoid impure static method. But if you have to use static method from a library or framework and you can’t avoid them, what can you do?

For example, we want to send sms notification using Twillo.

Twillo SDK provides static method Message.creator which is a factory method for constructing MessageCreator. The method that actually makes a request to Twillo to send sms is messageCreator.create(restClient).

Even though Message.creator is pure, but messageCreator.create(restClient) which is the method of the result of Message.creator is not. So we need to mock the create method by first stubbing return value of Message.creator. But since Message.creator is static, we don’t have our way in.

One might say: we can create a wrapper class around that static method, so that we can mock the wrapper instead.

But testing is all about increasing confidence in your code. Adding another level of indirection just for testing doesn’t increase confidence level in your system under test and adding more complexity to your code base.

So if adding wrapper helps you improving team’s coding experience consuming the API and it is being use a lot then it might worth investment, not just for the sake of testing.

Then, is there a leaner way?

Higher-order function FTW

We want to somehow create a path to replace Message.creator with something else. In Kotlin and a many languages these days treat function as a first-class citizen. The smallest reusable component is no more class but function. So you can pass function around like any other object.

In a strict functional and mathematical sense, function must be pure. But in Kotlin context, seems like function is allowed to be impure.

The difference between method and function in Kotlin is, while method is associated to an object, function doesn’t need to. You can see that the fun keyword which refers to function everywhere regardless of being a method declaration or top-level function declaration, which means function is a super-set of method, at least in this context.

But what is Higher-order function?

Higher-order function is basically means the function that has function as parameter(s) or returns function.

Even though function that does not have function as parameter(s) and not returning function is called first-order function, the term higher-order is being used here instead of second-order or third-order because, in theory, we can nest “function that has function as parameter(s) or returns function” infinitely many level. So that it’s higher than second or third order.

Let’s get back to our main topic. So we want to inject Message.creator into notify and we can achieve that by making notify a higher-order function so that we can pass Message.creator in as an argument.

In order to do that, first step, we need get the type right.

Let’s figure out the type of this particular function. Here is the implementation of the original creator in the SDK:

So it has a type

(PhoneNumber, String, String) -> MessageCreator

which means parameter types on the left side of the arrow “->” and return type on the right side.

Now let’s define our typealias to refer to this function type and name it for readability.

But now, we’ve just changed our interface, which is not really nice since normally we don’t need to pass creator to notify except in test.

In Kotlin, we can avoid that by providing default argument.

So now, our existing interface stays the same and we have our way in!

Let’s mock!

I’m using Spek and mockito-kotlin here.

So we define a creator that returns a mocked MessageCreator that stub create method to return Message we want.

You might ask, at line 22:

• Why don’t we just use Message constructor? => It’s private.
• Why don’t we mock getters? => It’s final.

So we end up using fromJson instead.

Edit 14 July 2018: David Kirchner point out that mockito 2 can mock final class and method already. See full response here

And I reference to creator function by using ::creator, it will regard as a value. The other way, we can use lambda and assign it to val instead of fun.

By using lambda, we can just ignore the arguments using _ since we are not using it in this context. This is not possible if we define it with fun.

For more info about how all these functions and lambdas work, you can find out in Kotlin documentation.

Now, we might want to verify if the creator is being called with correct arguments. The problem is mockito’s verify only supports method call verification. How can we verify creator that is not associate to any object?

But turns out, function is actually just a class with invoke method, so instead of creating function on our own, we can mock the function type. That way, mockito can verify the invoke method of that function if it’s being called by correct arguments. Here is how function being defined in it’s standard library.

Now we know that we can mock our function to verify the call and we can also stub the return value. Let’s do both!

As you can see, we can verify our function call and stubbing the return value of the static method without hacking the language.

Summary

We are leveraging higher-order function and default argument feature of the language to allow us to inject static method into a function that we want to test so that we can mock/stub it while retaining the old interface. Any language that has both features can also use the same trick as well.

I hope you’ve got the idea.

Thanks for reading! Enjoy testing :D

Follow me on twitter @ibossptk

Mocking static method in Kotlin was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

The main goal of this series is to discuss about how to make Flow more being more cooperative with you, catch more bugs, helps you being more confident and productive. Some topic might be general enough to be applicable to other type system as well.

I might also mention a bit about some academic sounding stuffs as well just to wet your appetite and have clearer picture of why things work the way it is and why something being named in a particular way, but I will put them in context as much as possible.

Here is the list of the topics:

1. Exhaustive checking with empty type
2. Determining return type by argument(s)

and more to come…

Follow me on twitter @ibossptk

Advance Flow type: Table of Contents

This post is the first post in Advance Flow type series and might be the least advance one but I think it is quite useful.

From the title, there are two interesting terms: exhaustive checking and empty type. What are they? Why do I need to care?

Exhaustive Checking

When we do conditional branching like if else or switch you might end up leaving some branch unhandled. Consider this simple function:

const f = (x: 'A' | 'B') => {
  if (x === 'A') {
    return 0
  }
}

Flow will not complain you anything, even though the 'B' case is not handled. The return type will be infered to ?number since it implicitly return undefined.

We can add else block to handle the rest of the case like this

const f = (x: 'A' | 'B'): number => {
  if (x === 'A') {
    return 0
  } else {
    return 1
  }
}

I also specify number as return type of this function to make sure that it will never implicitly return undefined.

Moving forward, we need to extract type of x out to somewhere else like this.

// type.js

type X = 'A' | 'B'

And the function lives in another file.

// function.js

const f = (x: X): number => {
  if (x === 'A') {
    return 0
  } else {
    return 1
  }
}

Now, let’s assume that type X is being used by someone else as well. If one day we have to add 'C’ to the type.

type X = 'A' | 'B' | 'C'

You have to go back and find every branching on X to make sure that it handle 'C' correctly and not just fall into default case which is not expected behavior.

What if I told you that if we just add two more line of code and you can prevent this problem? What if when we add 'C' our beloved type system will just guide us back to where we need to care about rather than tracing back yourself?

Or to put it in another way, to exhaustively check if we have already handled every cases.

Empty Type

In order to do that in Flow, you need empty type.

What is empty type?

Empty type is the type that has no element at all. So if we assert (x: empty)

const f = (x: X): number => {
  if (x === 'A') {
    return 0
  } else if (x === 'B') {
    return 1
  } else {
    (x: empty)
    throw new Error(`${x} is not an element of type 'X'`)
  }
}

It will have type error since x is so far refined to 'C' which means it still not empty. So all you need to do is to add another case to handle 'C' and Flow will be happy.

const f = (x: X): number => {
  if (x === 'A') {
    return 0
  } else if (x === 'B') {
    return 1
  } else if (x === 'C') {
    return 2
  } else {
    (x: empty)
    throw new Error(`${x} is not an element of type X`)
  }
}

If you don’t throw you will have a problem of implicitly return undefined. Apart from avoiding the implicitly return undefined problem, it is also useful for the case that some part of the code is still not covered by Flow or the data comes from IO boundary (eg. API calls) and, for some reason, doesn’t match the type definition (which I would suggest validating it beforehand using something like io-ts).

I would recommend using throw so when such a case happens, it’s not failed silently.

But there is another way to avoid implicitly return undefined just to show you an interesting property of empty type.

Which is by returning emptiness.

const f = (x: X): number => {
  if (x === 'A') {
    return 0
  } else if (x === 'B') {
    return 1
  } else if (x === 'C') {
    return 2
  } else {
    return (x: empty)
  }
}

After x being refined to this point, its type is no longer anything. It will work without explicitly asserting that x is empty as well, but the error will be a little bit more confusing since it will check type of x against number instead of empty. So, by returning x, the return type of this function will be

number | empty

since it could be either number or empty.

But for any type T, T | empty = T and empty | T = T because empty has no element, that’s why if we handle all the case before that last return, there should be no type error.

And you might notice that it’s the same as logic, for all proposition p, we can say that p v False = p and False v p = p and it’s not just a coincidence because empty type is corresponded to falsity and type also has strong correspondence to logic.

If you would like to go down the rabbit hole, you can have a look at Bottom type and Curry-Howard correspondance.

More example

Let’s look at more practical example.

We are going to create a validator that consume rule as data and spit out the result and here is the shape of rules.

type MaxRule = {
  type: 'MAX',
  maxValue: number,
}

type MinRule = {
  type: 'MIN',
  minValue: number,
}

type ForAllRule = {
  type: 'FOR_ALL',
  rules: Rule[]
}

type ForSomeRule = {
  type: 'FOR_SOME',
  rules: Rule[]
}

type Rule = MinRule | MaxRule | ForAllRule | ForSomeRule

Every rule has property type so we can refine the type using that property.

const validate = (value: number, rule: Rule): boolean => {
  switch (rule.type) {
    case 'MAX':
      return value <= rule.maxValue
    case 'MIN':
      return value >= rule.minValue
    case 'FOR_ALL':
      return rule.rules
        .reduce((acc, nextRule) => acc && validate(value, nextRule), true)
    case 'FOR_SOME':
      return rule.rules
        .reduce((acc, nextRule) => acc || validate(value, nextRule), false)
    default:
      (rule.type: empty)
      throw Error(`rule ${rule.type} is not being handled properly`)
  }
}

So now if we remove some case then it should have a type error.

Conclusion

Even though exhaustive checking with Flow might not be so beautiful comparing to some other language that has native support for it (eg. Scala, Haskell, Elm, OCaml) but at least we can make it work in JavaScript and it help us being explicit about what should be handled and let type system guide us where to fix or add stuffs.

For empty type itself, it also has some other use cases which we will discuss about it later in this series.

Thank you for reading. Feedback and comment are welcome.

Follow me on twitter @ibossptk

I have been doing Test-Driven Development (TDD) for quite a while and it’s great. It gives me a canvas (test file) to draft the design and way to think about how the interaction with other components should look like, what are the desired behaviors, and most of all, it gives me a very fast feedback loop.

When the time comes, you want to refactor. Doing TDD already gives you the safety net which is a bunch of test cases you have written to drive your implementation. When you refactor, according to Martin Fowler’s definition, you do not change the observable behavior.

Refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.

So, when refactoring, do tests need to be changed?

It depends on what level are you saying you are not changing behavior. Who is the observer? Interface changes require altering tests. Here, everything remains the same; just the form of input and output change even if they are isomorphic to previous ones. Does that count as changing behavior?

End-user might not notice but other consumers (your fellow developers and some other parts of the code base) will notice the change of the interface.

Even worse, the tests might know too much about implementation. You neither change any behavior nor interface but you still need to change the test.

TDD is useful for driving design but does not mean it always yields good design. If it goes wrong, the safety net ends up being spider web that prevents you from moving away instead. It turns out that you spend more time on maintaining the test and it discourages people from refactoring because it requires a lot of work.

So how can we stay sane?

Before anything else, think.

Sometimes people take TDD too far, they might say “don’t think, just write a test first” and hope that TDD will eventually guide us to better design. If not, we can refactor later. That doesn’t always work.

The thing is if we don’t think enough before writing the first test, the poor problem modeling will leak into implementation and spread like wildfire.
At some point, you will realize that the thing you just wrote doesn’t fit well in the bigger picture and you will spend more and more time refactoring, or even worse, you don’t have enough time to refactor it because of the so-called delivery pressure. Your teammates start building stuff on top of it and it’s getting even costlier to refactor. Domain understanding is a very important key to successful software development.

So before writing any tests, ask yourself

What problem are we trying to solve?

We are solving problem not just building feature. So we should know what the problem is, and write it down. Once we know what it is, think about how to model it to fit in the context and constraints we have. While I am at work, I disturb business analyst and UX designer quite frequently (and other roles as well but that’s less frequent) to understand the logic and reason behind a user story before diving into technical details. Understanding the problem we are trying to solve is the very first step of good problem modeling.

Pen and paper or whiteboard are awesome tools for problem modeling. Computer tends to be a distraction since it gives us the urge to implement without thinking carefully enough.

So, to me, this is like a micro version of traditional analysis and design. Avoiding big design up front doesn’t mean you should ignore planning and just go code with blind eyes. You can’t be agile if you don’t plan for the design that is easy to change, evolve or even throw it away.

If you have never watch Hammock-driven development by Rich Hickey (the guy who creates Clojure), I would recommend you to watch it. It will give you some interesting ideas about how to think about problems.

Now we understand more about the problem, let’s put our understanding into…

Contract

When we are coding, we need to think about how a function, module or class will be used, how do the inputs and outputs look like, what are the constraints we want to put on. We write down the contract in our code to filter out unnecessary possibility we need to handle.

One way of doing it is by using type.

Types represent set of possible inputs and outputs. With good type system, it gives you type-level feedback by the compiler which is even faster than test. At that time you are focusing more on designing interface, not the underlying implementation. You can use types to eliminate potential bugs, but how far you can go also depends on how sophisticated type system your language of choice is.

In typed-functional setting, people tend to use algebraic data types to model problem. The idea is quite simple and can be encoded in class as well.

But that’s not the only way. The goal is to put some constraints on the input and output and document it. For example, Clojure, which is a dynamically typed language, has clojure.spec which gives you ability to do so. And it comes with test.check which can also generate tests by spec you defined. Or in JavaScript, there is a library called tcomb which allows you to perform type checking at runtime and it’s quite flexible customizing the checks.

Even without all the tools, it’s good to understand how it should look like. At least think about it before you start writing test. Designing data structure to match the nature of the problem reduces the number of tests you need to write and also makes your implementation simpler.

If you would like to know more about this topic, I would recommend Making Impossible States Impossible and Designing with types. They are all using typed-functional language to demonstrate but I think the idea is applicable to OOP as well.

Then write the first test

After we filter out lots of undesirable states by types, it’s time to be more specific. Guiding by examples, TDD is a good tool for driving design of the internal implementation of a function or a class. As I mentioned before, test file is like a canvas for us to paint our design. It will show you how it will be used and it’s the place to define the desired behavior that type can not express. You will sense the smell that if it takes too much effort to setup the test or it’s hard to assert the behavior.

As we go step by step, from very basic cases to more complicated cases, our design grows within the boundary we have defined. We add tests. We add new code. We have all the tests for regression testing and then refactor. One thing to keep in mind along the way is that we should keep the test away from the implementation detail as much as possible or else we will end up in the state in which tests hinder you from refactoring.

One tip that makes me feel productive is listing all the cases even without any assertion (aka. pending tests) to have the milestones for the implementation. By doing this, you will see the clear outline of the function or class behavior.

More cases can be added along the way if we can think of other valuable ones. Keep in mind that more tests don’t always mean good, but always mean more code to maintain. Write tests just enough to be confident and keep them in the state that is maintainable like application code.

It’s all about quality

Good design is the cheapest way to prevent bugs. From careful thoughts to types and then tests provide more abstract picture of the system: how do the components communicate with each other, what are the interfaces, what are the behaviors. They all affect how we implement one small part of the system. Writing test before anything else might lead to wrong focus in the design process.

It’s about iterative and incremental change but at different level and different cycle time. TDD is the shortest one, while the rest are longer.

There are also times that TDD doesn’t work well. If that’s the case, try something else.

TDD is not a means to an end, good quality software is.

Follow me on twitter @ibossptk

Think first, test later was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

บังเอิญว่าผมอาจจะต้องเขียน mobile application เลยมาจับ Swift ซะหน่อย บังเอิญว่าทั่น Erik Meijer (ผู้สร้าง LINQ และ Rx) แกบอกว่า

Erik Meijer on Twitter

At this point, @SwiftLang is probably a better, and more valuable, vehicle for learning functional programming than Haskell.

ถ้าเฮียจะพูดขนาดนี้ ไหนขอลอง functional Swift ซะหน่อยซิ

ลองไปลองมา ก็ไปสะดุดกับ Optional (หนึ่งในวิชามารของ functional programming) เพราะว่าหน้าตามันประหลาดกว่าชาวบ้าน อย่าง Scala, Java 8 อยู่พอสมควร แล้วมีวิธีจะใช้งานมันแบบประหลาดๆ เยอะมากเลย ไม่แน่ใจว่าดีหรือไม่ดีเหมือนกัน เดี๋ยวเรามาดูกัน

related posts

• Hello, Functional Programming!
• ลาก่อย for loop: map, reduce และผองเพื่อน

แล้ว Optional มันคืออะไร?

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

เรื่องนี้เกี่ยวข้องกับ null reference (ใน Swift คือnil) ซึ่งหลายคนอาจจะเคยได้ยินแล้วว่า Tony Hoare คนที่คิดค้น null reference ขึ้นมาเพื่อใช้ในภาษา ALGOL W (และเป็นคนเดียวกับคนสร้าง CSP ซึ่งเป็น formal language เบื้องหลัง actor model และ go routine ด้วย) แกบอกว่า null reference เนี่ย

I call it my billion-dollar mistake

แกอดไม่ได้ที่จะใส่ null reference ลงไปเพราะมัน implement ง่าย แต่ผลที่ตามมาคือ error มากมาย, ช่องโหว่, crash ซึ่งคงจะทำให้สูญเสียกันเป็นพันล้านดอลล่า และผู้คนต้องปวดใจกันมาตลอด 40 ปี…

แล้วชาว functional แก้ปัญหานี้ยังไง?

อะไรปัญหาเยอะ ก็เอามันไป “ห่อ” ซะสิ

พอเราห่อมันแล้ว ชีวิตก็ไม่ต้องมาคอย if value == nil อยู่ตลอดเวลา ก็ใช้มันแบบที่มันห่อๆ ไว้แล้ว แล้วค่อยไปจัดการกับมันตอนปลายทางแล้วกัน

*จากนี้ไป แนะนำให้เปิด playground มาพิมพ์เล่นตามไปด้วยเพื่อเพิ่มอรรถรส!

หน้าตามันเป็นอย่างงี้ครับ

let optionalNumber: Int? = 1
let optionalString: String? = nil

ตอนแรกที่ผมเห็นผมก็งงๆ หน่อยว่ามันทำอะไรของมัน

สุดท้ายผมพบว่ามันเป็น syntactic sugar เฉยๆ ความจริงมันมีค่าเท่ากับแบบนี้

let optionalNumber: Optional<Int> = Optional(1)
let optionalString: Optional<String> = Optional.none

จะเห็นได้ว่าเจ้า ? เนี่ยมันไปแอบห่อเจ้าก้อนหลัง = ให้ด้วย Optional ซึ่งก็คิดซะว่า ไอที่ประกาศไว้นี่จะเป็น Int String หรือไม่มีอะไรอยู่ในกอไผ่ก็เป็นได้ ซึ่งทำให้มันเห็นได้ชัดมากๆ ว่าตรงไหนที่มันมีโอกาสจะไม่มีอะไรเลยได้บ้าง จะได้จัดการกับมันถูก

แถมถ้าลองแบบนี้ดู เราจะ assign nil ให้กับ type String

let optionalString: String = nil

// => error: nil cannot initialize specified type 'String' 
let optionalString: String = nil

โดนด่าเลย :(

เราเลยมั่นใจได้ว่า ไม่ว่ายังไง ถ้ามันไม่ได้เขียน type แบบมี ? มา แม่งไม่ nil แน่ๆ

นอกจากเราจะแอบห่อตัวแปรได้แล้ว เรายังแอบห่อผลลัพธ์ของทั้ง function ได้อีกด้วย

func half(number: Int) -> Int? {
    return number % 2 == 0 ? number / 2 : nil
}

half(number: 10) // => Optional(2)
half(number: 1)  // => Optional.none

จะเห็นได้ว่า แม้ว่าเรา return ตัวเลข หรือ nil เปล่าๆ ไว้ แต่ return type บอกว่าเป็น Int? มันเลยห่อผลลัพธ์ด้วย Optional ให้เรียบร้อย

ห่อเอาไว้แล้วจะใช้งานมันได้ยังไง

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

อันนี้เป็นท่ามาตรฐานของบรรดาของที่ถูกห่อ บางคนคงเคยใช้กับพวก array มาแล้ว ซึ่งก็ไม่ต่างกันเท่าไหร่ นั่นก็คือ map และ flatMap นั่นเอง

1) map

สมมติว่าเรามี name: String? อยู่ เราสามารถทำแบบนี้ได้

name.map { s in s.characters.count }

จะเห็นได้ว่า function ที่เราใส่เข้าไปใน map รับ argument เป็น String ธรรมดา ถ้า name: String? = "Boss" map แล้วจะได้ Optional(4)ที่มี type เป็น Int?

สิ่งที่มันทำคือ มันแกะห่อ แล้วเอาของจากในห่อ ไปยัดใส่ function ให้ evaluate จากนั้นก็ยัดกลับเข้าไปในห่ออีกรอบ สุดท้ายแล้ว ผลลัพธ์ของ map จะกลายเป็นอะไรก็ตามที่เป็น return type ของ function ที่ pass ไป แล้วห่อด้วย Optional อีกทีนั่นเอง

แต่ถ้าเป็น name: String? = nil แล้ว name มีจะค่าเท่ากับ Optional.none พอเรา map แล้วจะได้ Optional.none เหมือนเดิม เพราะเมื่อเราจะทำอะไรกับความว่างเปล่า เราก็จะได้ความว่างเปล่ากลับมาเสมอ

2) flatMap

สมมติว่าเรามีเราอยากจะแบ่งครึ่ง 12 ซักสามรอบด้วยเจ้า half ที่เขียนไว้ข้างบน ทำยังไงดี

func half(number: Int) -> Int? {
    return number % 2 == 0 ? number / 2 : nil
}

ลอง map ดูแล้วกัน

half(number: 12)
    .map(half)
    .map(half)

// error: cannot convert value of type '(Int) -> Int?' to expected argument type '(Int?) -> _'

ปรากฏว่า โค้ดข้างบนนี้ใช้ไม่ได้ เพราะผลลัพธ์ของ half(number: 12).map(half) จะกลายเป็น typeInt?? เนื่องจาก ผลลัพธ์จาก type ของ half คือ Int -> Int? พอเรา .map(half) ผลลัพธ์ที่เป็น Int? อยู่แล้วจะถูกห่อด้วย Optional อีกที กลายเป็น Int?? ก็เลยเอาไป .map(half) ต่อไม่ได้ เพราะพอแกะห่อ Int?? จะได้ Int? แต่ half ต้องการ Int เปล่าๆ เป็น argument

ในกรณีนี้ flatMap ช่วยคุณได้

half(number: 12)     // => Optional(6)
    .flatMap(half)   // => Optional(3)
    .flatMap(half)   // => Optional.none

สิ่งที่มันทำก็เหมือน map เลยครับ แค่ตอนที่หลังจาก evaluate function ที่ใส่เข้าไปแล้ว มันจะเอาผลลัพธ์ที่ได้มาเนี่ย ไปสลายห่อทิ้ง (flatten) ทำให้ type หลังจาก flatmap ผลลัพธ์จบด้วยห่อชั้นเดียวเสมอ

อันนี้แถม โดยปกติแล้ว Optional จะมี function filter มาให้ โดย pass function ที่ return Bool (predicate function) คือถ้าผ่านเงื่อนไขก็โอเค return ตัวเดิม ไม่ผ่านก็จะกลายเป็น Optional.none

แต่ใน Swift ดันไม่มี!

แต่เราก็ทำให้มันมีได้ไม่ยากเพราะมันมี extension ให้เราใช้ implement เพิ่มเติมจากของที่มีอยู่แล้วได้ (เหมือน Open class ของ Ruby เลย)

extension Optional {
    func filter(_ predicate: (Wrapped) throws -> Bool) rethrows -> Wrapped? {
        switch self {
        case .some(let wrapped):
            return try predicate(wrapped) ? wrapped : nil
        case .none:
            return nil
        }
    }
}

แล้วเราจะได้ของแบบนี้

let evenNum: Int? = 12
let oddNum: Int? = 3
let noNum: Int? = nil

func isEven(num: Int) -> Bool {
    return num % 2 == 0
}

evenNum.filter(isEven) // => Optional(12)
oddNum.filter(isEven)  // => Optional.none
noNum.filter(isEven)   // => Optional.none

ทั้งนี้ทั้งนั้นmap flatMap และ filter ไม่ได้ไปแก้ค่าของตัวแปร แต่จะ return Optional ตัวใหม่ออกมาทุกครั้ง เพื่อรักษาความ immutable เอาไว้

3) Optional Chaining

สมมติว่าเราต้องการอ้างอิงถึง attribute หรือ function ของของที่ถูกห่อ เราทำอะไรได้บ้าง ตัวอย่างเช่น

class Person {
   let name: String

   init(name: String) {
     self.name = name
   }
}

class Dog {
    let owner: Person?

    init(owner: Person?) {
        self.owner = owner
    }
}

let ownedDog = Dog(owner: Person(name: "I'Boss"))
let strayDog = Dog(owner: nil)

เราสามารถไปถึงชื่อเจ้าของได้ด้วย map

ownedDog.owner.map { person in person.name } 
// => Optional("I'Boss")

แต่ถ้าใน map ไม่ได้จำเป็นต้องมีอะไรเพิ่มเติมนอกจากเรียก name แล้ว เราสามารถใช้ Optional Chaining แทนได้

ownedDog.owner?.name // => Optional("I'Boss")
strayDog.owner?.name // => Optional.none

ถึงเวลาต้องใช้แล้ว มาแกะห่อกันเถอะ!

เราไม่สามารถให้มันอยู่ในห่อตลอดไปได้ วันนึงเราก็ต้องแกะมันออกมาใช้อยู่ดี ในภาษา Swift มีท่าแกะห่อให้เลือกใช้เยอะมาก ลองไปดูกัน

4) การแกะห่อแบบไม่ปลอดภัย

ถ้าเรามี

let optionalNumber: Int? = 1
let optionalString: String? = nil

เราสามารถทำแบบนี้ได้ครับ

optionalNumber! // => 1

แต่ๆ ถ้าสมมติว่ามันเป็น nil ล่ะ

optionalString!

// fatal error: unexpectedly found nil while unwrapping an Optional value

แน่นอนว่ามันเป็น runtime error ไม่ใช่ compile time มันเลยน่ากลัวมาก มันอาจจะทำให้เกิดพฤติกรรมที่เราไม่คาดคิดได้ ถ้าจัดการกับมันไม่ดี

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

optionalString.unsafelyUnwrapped

// fatal error: unexpectedly found nil while unwrapping an Optional value

5) การแกะห่อโดยปริยาย

เราสามารถเขียน ! ต่อท้ายจาก type ได้แบบนี้

let number: Int! = optionalNumber
number // => 1

มันก็ดูคล้ายๆ .unsafelyUnwrapped เนอะ แต่…

let string: String! = optionalString
string // => nil

มันไม่ error? อะไรฟระ?

จริงๆ ผมหลอกคุณ เพราะค่าที่แท้จริงของ number และ string มันเป็นแบบนี้

number // => ImplicitlyUnwrappedOptional(1)
string // => ImplicitlyUnwrappedOptional<String>(nil)

ครับ เจ้า type ที่ตามด้วย ! อย่าง Int เนี่ย มันคือ ImplicitlyUnwrappedOptional<Int> นั่นเอง

แล้วมันมีประโยชน์อะไร?

เรียกได้ว่า มันคือ optional type ที่จะแกะห่อ (เหมือนที่เราเรียก ! ต่อท้าย) แทนเราให้เองตอนที่พยายามใช้มัน เช่น

optionalNumber! + 1 // => 2
number + 1          // => 2

optionalString!.capitalized  

// fatal error: unexpectedly found nil while unwrapping an Optional value

string.capitalized 

// fatal error: unexpectedly found nil while unwrapping an Optional value

ซึ่งเจ้า ImplicitlyUnwrappedOptional เนี่ย มี use cases ที่น่าสนใจหลายอย่างเวลาที่เรา develop application จริงๆ ลองดูเพิ่มเติมได้ที่นี่

6) nil-coalescing operator `??`

อันนี้ง่ายมาก ถ้าเป็น Java กับ Scala พวก Optional จะมี function orElse หรือ getOrElse อยู่ แปลว่าเราจะเอาค่ามันออกมาจากห่อนั่นแหละ แต่ถ้าไม่มี ก็ขอ default value ให้หน่อย

สำหรับ swift มี syntax น่ารักๆ แบบนี้

let optionalString: String? = nil
optionalString ?? "string is missing" // => "string is missing"

ซึ่งใน official documentation เขาบอกว่า มันคือตัวย่อของ

optionalString != nil ? optionalString! : "string is missing"

ซึ่งวิธีนี้ปลอดภัยในการใช้งาน เพราะยังไงก็ไม่ได้ nil ออกมาให้ fatal error แน่ๆ

7) Optional Binding

แบบแรก if let

“ถ้าไม่ nil ขอเอาค่าไปใช้หน่อย”

if let string = optionalString {
    print(string.capitalized)
}

ถ้าค่าใน optionalString เป็น nil ก็จะไม่ทำอะไรเลย แต่ถ้า มีค่าอยู่ block นี้ก็จะทำงาน เจ้า string (แกะห่อแล้ว และเปลี่ยนตัวแรกเป็นอักษรตัวใหญ่) ก็จะถูก print ออกมาทาง console

เราสามารถเพิ่ม condition ได้ด้วย เช่น

if let string = optionalString, string.characters.count > 3 {
    print(string.capitalized)
} else {
    print("not long enough!")
}

ขา functional (เหมือนผม)อาจจะหงุดหงิด อาจจะหงุดหงิดนิดหน่อยเพราะ if ไม่ใช่ expression ทำให้ เราเอาเจ้าก้อนนี้ไป assign หรือ เอาค่าไปใช้ต่อเลยไม่ได้ (เป็นสาเหตุที่ทำให้ผมใช้ตัวอย่างที่มี side-effect อย่าง print)

แน่นอนว่าเราก็ใช้ guard แบบนี้ได้เหมือนกัน วิธีคิดแบบ guard คือเคลียร์อันที่ไม่อยากได้ออกไปก่อน แล้วค่อยทำอันที่สนใจ ซึ่งเอาไว้ใช้กับ loop หรือ function

func guardShortString(optionalString: String?) -> String {
    guard let string = optionalString, 
          string.characters.count > 3 else 
    {
        return "not long enough"
    }
    return string.capitalized
}

guardShortString(optionalString: "boss") // => "Boss"
guardShortString(optionalString: "me")   // => "not long enough"

8) switch และ pattern matching

เราสามารถใช้ switch เพื่อแกะห่อ Optional ออกมาได้แบบนี้

switch optionalString {
case .some(let string):
    "the wrapped string is \(string)"
case .none:
    "there's nothing here"
}

บางคนก็อาจจะรู้สึกว่า อ๊ะ นี่มัน pattern matching นี่หว่า

บางคนอาจจะพอใจแล้วว่า เอ้อเราสามารถ switch แบบนี้ได้นะ แต่สำหรับขา functional อย่างผมจะหงุดหงิดนิดนึง

ถ้าใครเคยเขียน Scala มาจะเจอของแบบนี้

val s = optionalString match {
    case Some(string) => s"the wrapped string is $string"
    case None => "there's nothing here"
}

จะเห็นได้ว่าผมสามารถเอาไปใส่ตัวแปรได้เลย if ก็ทำแบบนี้ได้เหมือนกันแต่ Swift ทำไม่ได้ เพราะฉะนั้น โค้ด Swift ข้างบนจะไม่มีประโยชน์อะไรเลย เพราะในแต่ละ case ไม่ได้เอาไปใช้อะไรเลย

จะทำยังไงให้มีประโยชน์โดยไม่ต้องไปแก้ค่าตัวแปร หรือสร้าง side-effect อื่นๆ ? เพราะอยากจะเขียนให้มัน functional

ถ้าเราเขียนโค้ดโดยยึด Single Responsibility Principle อยู่แล้ว สุดท้ายเราคงหนีไม่ค่อยพ้น function เล็กๆ หน้าตาแบบนี้

func describe(optionalString: String?) -> String {
    switch optionalString {
    case .some(let string):
        return "the wrapped string is \(string)"
    case .none:
        return "there's nothing here"
    }
}

ซึ่งสำหรับผมก็พอใจแล้วนะ แต่ถ้าอยาก treat มันเป็น expression แบบที่ Scala ทำข้างบน ก็อาจจะใช้ closure เข้ามาช่วย

let s: String = {
    switch optionalString {
    case .some(let string):
        return "the wrapped string is \(string)"
    case .none:
        return "there's nothing here"
    }
}()

ซึ่งไอเดียคือเราสร้าง anonymous function ที่ในที่นี้มี type () -> String ขึ้นมา แล้วเรียกใช้มันทันที ทุกอย่างจะจบในนั้น แล้วคืนค่าที่เราต้องการออกมาได้ ซึ่งเราก็เอาไปใช้กับ if ข้างบนได้เช่นกัน

บทสรุป

จบไปแล้วสำหรับ 8 กระบวนท่า Optional สำหรับผมแล้ว มันมีท่าให้ใช้เยอะ เหมือนจะสะดวก แต่แอบรู้สึกว่ามันซับซ้อนเกินความจำเป็นไปนิดนึง เพราะต้องทำความเข้าใจ syntax ที่มันไม่ค่อย consistent เท่าไหร่ ซึ่งบางคนก็อาจจะชอบ บางคนอาจจะไม่ชอบ

ในแง่ความสะดวกในการเขียน Swift ใน functional style ผมว่าก็ใช้ได้เลย ถึงแม้จะมีข้อจำกัดบางอย่าง แต่โดยรวมแล้วก็น่าสนใจ

ส่วนใครสงสัยว่า Optional มันเกี่ยวกับ functional programming ยังไง Optional คือ Maybe monad ใน Haskell ถ้าใครสนใจเรื่องนี้ ลองไปดู Functors, Applicatives, And Monads In Pictures ได้ หรือเวอร์ชั่นแปลเป็น swift ก็มีครับ ลองไปดูกัน

ขอบคุณที่รับชม

functional programming FTW!