Candide ตอนที่ 1

หัดแปล

โอเคนี่เป็น Category ใหม่ของ Blog นี้ซึ่งก็คือ “หัดแปล” นั่นเอง Category นี้ก็ไม่มีอะไรมากไปกว่าหัดแปล โดยเรื่องแรกจะเอา Candide มาแปลซึ่งเป็นนิยาย ของ VOLTAIRE โดยผมเอาต้นฉบับทั้งหมดมาจาก The Project Gutenberg EBook สำหรับใครอยากอ่านต้นฉบับภาษาอังกฤษเดี๋ยวผม Ref ไว้ด้านล่าง

ส่วนการแปลก็จะแปลจากคนอ่านภาษาอังกฤษไม่ออก จับศัพท์ไม่ได้ ดังนั้นมันจึงเป็นคำแปลที่ไม่ค่อยสละสลวย และอาจจะไม่รู้เรื่องด้วย

ตอนที่ 1 : CANDIDE นั้นมาอยู่ในปราสาทที่สวยงามอย่างได้อย่างไร และ เขาถูกกล่าวถึงอย่างไร

ณ ปราสาทแห่งหนึ่งใน Westphalia ซึ่งเป็นของบารอน Thunder-ten-Tronckh มีชายผู้ซึ่งอาศัยอยู่ตั้งแต่เด็กจนถึงวัยหนุ่ม เป็นผู้มีมารยาทอ่อนโยน ใบหน้าของเขานั้นแสดงออกถึงจิตวิญญาณของเขา เขาผู้นี้เป็นการรวมกันระหว่างความสัตย์และความเรียบง่ายของจิตวิญญาณ ซึ่งด้วยเหตุผลนี้เขาจึงถูกเรียกว่า Candide (เป็นภาษาฝรั่งเศสแปลว่าตรงไปตรงมา) ข้ารับใช้เก่าของครอบครัวได้สงสัยว่าเขานั้นเป็นลูกชายของน้องสาวบารอนซึ่งได้เสียกับสุภาพบุรุษแสนดีคนหนึ่งแต่เธอนั้นไม่ได้แต่งงานเนื่องจากสุภาพบุรุษผู้นั้นไม่สามารถพิสูจน์ว่าตนเป็นผู้มีชาติตระกูล (ตรงนี้แปลมั่วนะครับ เพราะมันพูดถึงการพิสูจน์อะไรสักอย่างได้ไม่ครบ เพราะตระกูลเขาหายไปตามกาลเวลา)

บารอนผู้นี้มีอำนาจมากใน Westphalia สำหรับปราสาทของเขานั้นไม่ได้แค่ประตูแต่ยังมีหน้าต่างด้วย (อะไรของมันวะ ปราสาทก็ต้องมีหน้าต่างปะวะ หรือหมายถึงหน้าต่างที่เปิดปิดได้) ห้องโถงของปราสาทนั้นถูกตกแต่งด้วยพรมแขวน สุนัขทุกตัวในฟาร์มนั้นถูกเลี้ยงไว้เพื่อเป็นสุนัขล่าเนื้อ และเขาคือผู้ช่วยดูแลหมู่บ้านแห่งนี้ คนในหมู่บ้านเรียกเขาว่า “ใต้เท้า” แต่พวกเขาก็ยังหัวเราะกับเรื่องราวของบารอนผู้นี้

ภรรยาของบารอนผู้นี้มีน้ำหนัก 350 ปอนด์ (ประมาณ 158.7 กิโลกรัม) ดังนั้นเธอจึงสามารถถูกจดจำได้ง่ายและเธอได้รับเกียรติและความเคารพภายในบ้านอย่างดี ลูกสาวของเธอ Cunegonde อายุ 17 ปีเป็นหญิงที่สดใสร่าเริง ส่วนลูกชายของบารอนดูเหมือนบารอนทุกประการ

Pangloss คือหมอดูประจำตระกูล ซึ่ง Candide ก็ได้รับการสั่งสอนจากเขา ซึ่ง Candide ก็ดูจะเชื่อหมอดูคนนี้ด้วยเนื่องจากลักษณะและความมีอายุของเขา Pangloss เป็นผู้เชี่ยวชาญด้าน อภิปรัชญา เทววิทยา จักรวาลวิทยา วิทยาศาสตร์ที่เกี่ยวกับความไม่เหมาะสม เขาทำการพิสูจน์ว่า ไม่มีผลถ้าไม่มีสาเหตุ และสิ่งที่เกิดขึ้นนั้นเป็นสิ่งที่ดีที่สุดที่เกิดขึ้น เช่น ปราสาทของบารอนนี้คือปราสาทที่สวยที่สุดของทุกปราสาท หรือ ภรรยาของบารอนคนนี้คือภรรยาที่ดีที่สุดของบารอน

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

Candide ได้ฟังเรื่องนี้ก็เชื่ออย่างบริสุทธิ์ใจ เขาคิดว่า Cunegonde นั้นสวยมากๆ ถึงแม้ว่าเขาจะไม่เคยบอกกับเธอเลยว่าเธอสวยแค่ไหน Candide ทำการสรุปว่าความสุขของเขาอย่างแรกเกิดจากการมีอยู่ของบารอน Thunder-ten-Tronckh อย่างที่สองคือการมีอยู่ของ Cunegonde อย่างที่สามคือการได้มอง Cunegonde ทุกวัน อย่างที่สี่คือการได้ฟังคำสอนของอาจารย์ Pangloss ซึ่งเป็นนักปรัชญาที่ดีที่สุดในแคว้นนี้หรือทั้งโลกก็ว่าได้

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

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

วันต่อมาหลังจากอาหารมื้อค่ำ Cunegonde และ Candide ได้พบกัน ณ หลังฉาก (เข้าใจว่าเป็นห้องที่เดินออกมาจากห้องอาหาร) Cunegonde ได้ทำผ้าเช็ดหน้าตก Candide ก็หยิบมันและส่งให้ Cunegonde Cunegonde ยื่นมือของเธอมารับ ชายหนุ่มได้จูบที่มือของเธอด้วยการแสดงออกที่เต็มไปด้วยความสง่างาม ริมฝีปากของเขาสัมผัสกับมือ ดวงตาที่เป็นประกายสบตากัน มือที่สัมผัสกัน

บารอน Thunder-ten-Tronckh ได้เดินผ่านที่หลังฉากนั้นและได้เห็นการกระทำเหล่านั้น ซึ่งเป็นผลให้ Candide ถูกไล่ออกจากปราสาท ส่วน Cunegonde ก็สลบลงไปในทันที และเมื่อตื่นเธอก็ถูกตบเข้าที่หูสองข้างอย่างรุนแรงทันทีที่เธอได้เจอกับแม่ของเธอ และนี่คือเรื่องราวอันน่าตกตะลึงของปราสาทที่สวยงามที่สุดและน่าพอใจที่สุดในบรรดาปราสาททั้งหมดที่เป็นไปได้

ref : https://ia800301.us.archive.org/25/items/candide19942gut/19942-h/19942-h.htm

สนิทใจ - Intimacy

สนิทใจ - Intimacy

สนิทใจ - Intimacy

หลังจากคุณอ่านหนังสือปรัชญา ไลฟ์โค้ช แนวทางพัฒนาชีวิตมาหลายเล่ม สิ่งหนึ่งที่ผมได้จากการอ่านหนังสือพวกนี้คือ “คิดก่อนเชื่อ” ใช่ครับ หนังสือพวกนี้บางส่วนจะบอกให้เชื่อ ลองใช้ใจเชื่อดูแล้วจะรู้สึก ใช่ครับมันจะไม่รู้สึกได้ไงก็ความรู้สึกนี่ นั่งดูหนังเศร้าก็รู้สึก ก็ต้องขอบคุณวิชาวิทยาศาสตร์ที่เรียนมาตั้งแต่เด็ก วิชาพระพุทธศาสนาเรื่องกาลามสูตรที่สอนเรื่องการเชื่อ จะเชื่อต้องพิสูจน์ ต้องหาเหตุหาผล ทำให้ผมได้เรื่อง “คิดก่อนเชื่อ” มาเป็นเกราะกันบ้า โอเคเรามาพูดถึงหนังสือเล่มนี้ “สนิทใจ” จาก OSHO ผู้ที่มีคนจำนวนหนึ่งนับถือดุจพระเจ้า อีกกลุ่มบอกว่าเป็นจอมลวงโลก ซึ่งผมจะตัดชื่อเขาออกไป จะดูเนื้อในของหนังสือเล่มนี้กัน

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

เรื่องลับที่ไม่อยากให้ลับ

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

เริ่มเข้าสู่เรื่องอารมณ์

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

การจะสร้างความสนิทใจ

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

ยอมรับตัวเอง

การยอมรับตัวเองคือยอมรับว่าตัวเองมีลักษณะอย่างไร อันนี้คนเขียนเขาเขียนไปถึงระดับจิตวิญญาณยกตัวอย่างเปรียบเทียบมากมายซึ่งผมรู้สึกเอียนในระดับนึง เหมือนจับเอาเรื่องเล่าของหลายๆที่ที่มันตรงกับเรื่องมาเล่ายกตัวอย่าง ถ้านึกไม่ออกนึกถึง “นิทานชาดก” ที่พระพุทธเจ้าเล่า(ใช้คำว่าคนที่อ้างว่าได้ยินพระพุทธเจ้าเล่าน่าจะถูกกว่า) ให้ฟังประกอบเหตุการณ์ การยอมรับตัวเองก็ว่าง่ายๆ ยอมรับว่าสิ่งที่ตัวเองเป็นไม่ได้น่าเกลียด ต้องกำจัดหรือทำลายทิ้ง เช่น ถ้าคุณรู้ว่าตัวเองเป็นคนโมโหง่าย คุณแค่ยอมรับว่าคุณเป็นคนโมโหง่าย ไม่ต้องมองว่ามันแย่ คุณแค่ต้องรู้ว่าคุณโมโหง่าย เวลาคุณโมโหก็ขอให้รู้ว่าโมโห เมื่อโมโหเสร็จคุณจะทำอะไรต่อ คุณควรขอโทษคนที่คุณโมโหใส่ บอกตามตรงว่าเมื่อกี้แค่โมโห แค่นั้น อ่านแล้ว WTF ไหมล่ะ ใช่ครับผมก็ WTF เหมือนกัน มันใช้กับพวก Case normal ได้ แต่ถ้าใช้กับพวก Worst case นี่จะบัดซบมากเช่น ถ้าใช้กับกรณีคนที่เป็นฆาตกรโรคจิตล่ะ แค่คิดก็ เหี้ย มากๆละ ในส่วนนี้ผมเข้าใจว่าทำไมเขาอยากจะสอนแบบนี้นะ คือ ถ้าเรายอมรับได้ว่าตัวเองเป็นคนแบบไหน รับว่ามันเป็นเรื่องธรรมดาที่คนปกติจะคิดแบบนี้ มันไม่ใช่เรื่องเลวร้าย (กรณีปกติ) เช่น ผู้ชายคนนึงจะมีรสนิยมชอบผู้หญิงในชุดนักเรียนใส่แว่น แม้เขาจะอายุร่วม 50 ปีแล้ว คุณอ่านประโยคที่ผมพิมพ์คุณอาจจะบอกว่า “ไอคนนี้มันตาแก่ตัณหากลับ” แต่ๆๆๆ แล้วใครเป็นคนกำหนดเรื่องนี้เป็นความไม่ปกติล่ะ มันผิดตรงไหนที่ชายวัย 50 จะชอบสาวรุ่นลูกในชุดนักเรียนใส่แว่น อะไรไปฝังสมองพวกคุณว่ามันไม่ถูก ใครล่ะ ศาสนา สังคม หรืออะไร (แต่จริงๆเรื่องนี้มันก็จะขัดๆเมื่อเป็น Worst case อย่างฆาตกรฆ่าคนเพราะทุกคนต่างรู้ว่าการฆ่าคนเป็นเรื่องไม่ดีซึ่งผมก็ไม่รู้ว่าใครโปรแกรมสิ่งดีไม่ดีเหล่านี้ขึ้นมาในสมอง )

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

ยอมรับผู้อื่น

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

เมื่อต่างคนต่างยอมรับกันไม่มีกำแพง ทุกคนก็สนิทใจกัน

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

คิดง่ายไป

ในทางทฤษฎีเรื่องนี้เป็นเรื่องที่น่าสนใจครับ ผมล่ะโคตรชอบ แต่ๆๆๆ (ไปติดคำนี้มาจากไหนวะ) ในความเป็นจริงแค่กรณี Worst case เรื่องฆาตกร เราจะยอมรับคนมีรสนิยมฆ่าคนได้เหรอ คนเขียนมันไม่ได้เขียนไว้นี่… ใช่ครับคนทุกคนมักจะเขียนแนวคิดวิธีการที่มีแต่ด้านดี ไม่เคยพูดข้อเสีย หรือกรณีที่มันขัดกับแนวคิด แบบนี้วิทยาศาสตร์มันเลยดีไง เพราะมันต้องผ่านการตรวจสอบ การทดลองเพื่อทำลายแนวคิดนั้น ตั้งกรณีต่างๆขึ้นมา อย่างทฤษฎีสัมพัทธภาพทั่วไปของไอสไตน์ยังมีปัญหาในพื้นที่สุดขั้วรูปแบบหนึ่งเลย ซึ่งก็ต้องเขียนเป็น Exception ไว้ว่าถ้าเข้ากรณีนี้จะใช้ไม่ได้ แล้วเราจะมองกรณีฆาตรกรให้เป็นเรื่องปกติได้เหรอ ฆ่าคนทั้งคน คุณยอมรับได้เหรอ การใช้อารมณ์โมโหในการคุยกัน คุณยอมรับได้เหรอ ทำไมถึงยอมรับไม่ได้ อะไรเป็นตัวแบ่ง สุดท้ายก็คือความรู้สึกส่วนตัว ซึ่งเป็นเรื่องที่ได้รับการปลูกฝังมาจากสังคมนั่นเอง แล้วมันก็กลายเป็นงูกินหาง เพราะคนเขียนด่าสังคมว่าหล่อหลอมคนด้วยบรรทัดฐาน แต่ถ้าไม่มีบรรทัดฐานจะเอาอะไรตัดสินเรื่องที่ยอมรับได้ยอมรับไม่ได้ล่ะ

สุดท้ายมันเป็นเรื่องของบุคคล

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

ก่อนจาก

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

Melt Mallow Goodbye stage

ความทรงจำ

ตอนเด็กเคยดูสารคดีเกี่ยวกับศิลปะแบบหนึ่งที่พูดถึงการพยายามวาดรูปให้เร็วที่สุดเพื่อรักษาบรรยากาศในขณะนั้นได้มากที่สุด (ก็เพราะสมัยนั้นไม่มีเครื่องถ่ายภาพ เครื่องอัดวิดีโอ) วันนี้ก็เลยยึดหลักการนั้นในการเขียนบันทึกความทรงจำความรู้สึกก่อนที่มันจะเลือนลางไปมากกว่านี้ (จริงๆอยากจะเขียนตั้งแต่กลับมาละ แต่ไม่ไหวมันดึกเกิน) เผื่อในอนาคตเวลากลับมาอ่าน Blog จะจำได้ว่าวันนั้นเป็นยังไงเกิดอะไรขึ้นบ้าง แล้วมีความรู้สึกยังไง

การได้เจอวงนี้ครั้งแรก

วงนี้รู้จักครั้งแรกไปงาน Idol expo ที่ไบเทคบางนา ตอนนั้นคือจะไปดู นิโกะ siamdream แต่มาเห็นโปรโมทวงใหม่วงนี้ก็เลยเข้าไปดู เฮ้ยนี่มันวงดนตรีนี่นา คือวงดนตรีจริงๆเล่นดนตรีจริงๆ กีต้าร์ กลอง เบส คีย์บอร์ด มีหมด เล่นเอง ร้องเอง เฮ้ยเจ๋ง เสียดายที่งานนั้นเครื่องเสียงไม่ดี คุณภาพเสียงเลยไม่ดีตาม เลยฟังไม่ค่อยสนุก พอฟังเสร็จก็เลยเชกิด้วย ซึ่งน้องที่ไปเชกิด้วยแต่ละคนน่ารักมากๆ ไม่ว่าจะน้องปิ่น น้องมุก น้องข้าวเจ้า (เสียดายที่ไม่ได้เชกิกับทุกคน เพราะเงินมีจำกัด) จากนั้นก็ติดตามผลงานของวงนี้เรื่อยๆมา งานไหนพอเดินทางไปได้ก็ไป งานไหนไปไม่ได้ก็ดู โดยเพลงของวงนี้นั้นความหมายดี มี Concept ที่ดี ไม่ว่าจะ

Mirror

ที่พูดถึงไม่ว่าจะเศร้าใจแค่ไหน ไม่มีใครเข้าใจแต่อย่างน้อยมีตัวเราที่ยังเข้าใจ

เป็ด

พูดถึงคนที่ทำอะไรได้หลายอย่างแต่ไม่เก่งสักอย่าง ซึ่งขัดกับกระแสหลักของสังคมที่ต้องการ specialist ในสายงานนั้น คนเหล่านี้จึงถูกตีค่าว่าด้อยกว่าคนทั่วไป ซึ่งจริงๆคนจำพวกเป็ด (generalize) นั้นก็เป็นทักษะหนึ่งที่เป็นที่ต้องการในปัจจุบันที่บริษัทนั้นเน้นไปที่จำนวนคนที่น้อยแต่ต้องการคนที่ทำได้หลายอย่างๆแทน ส่วนงาน Specialist สุดๆนั้นส่วนใหญ่จะถูก Outsource ไปให้บริษัทอื่นทำหมดแล้ว ตัวอย่างง่ายๆในสายงานคอมพิวเตอร์ น้อยบริษัทนักที่จะจ้าง specialist ด้านการทำ Image processing ส่วนใหญ่จะ Outsource ให้บริษัทที่เชี่ยวชาญทำ

Which Witch

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

Sea Lestrail Entertainment

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

Goodbye stage

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

การแสดงในงาน

ก็เขาจัดงานที่ The Street รัชดาที่ชั้น 3 Horizon ซึ่งเป็นเหมือนห้องซ้อมดนตรีอะนะ ซึ่งเขาไปจัดในห้องที่จัดการแสดงได้ น้องก็แสดงเพลงของวงเพลงต่างๆไล่ตาม Single ไปตั้งแต่ Single แรก Mirror -> เป็ด -> Which Witch รอบนี้ได้ฟังเสียงแบบเต็มๆ คือฟังแล้วสนุกมาก ดีกว่าตอนฟังที่งาน Idol หลายเท่าตัว จากนั้นน้องก็เริ่มแสดงเพลงของ Unit ตัวเอง โดยเริ่มจาก

Philophobia

เพลงจาก Unit ของน้องปิ่นกับน้องมุก แสดงเพลง Philophobia (โรคกลัวความรัก) น้องทั้งคู่เต้นน่ารักมากๆ ซึ่งเพลงนี้น้องมุกแต่งท่อน Rap เอง ส่วนน้องปิ่นคิดท่าเต้น โอ้ย น่ารักเหมือนใน MV เลย

My Moon

เพลงจาก Unit ของน้องข้าวเจ้ากับน้องแจม โดยส่วนตัวชอบเป็นเพลงที่ชอบมาก เนื้อหาเกี่ยวกับการคิดถึงใครบางคนแล้วเราเปรียบเขาเหมือนดวงจันทร์ (+ น้องข้าวเจ้าอยู่ Unit นี้ เลยยิ่งชอบ ) อีกทั้งเพลงยังเปิดช่องให้เราตีความหมายของพระจันทร์ด้วย ชุดน้องในงานแสดงน่ารักทั้งคู่เลย แต่งสีขาวสีดำตัดกัน

การแสดงการเต้นของ น้องแพร น้องบี

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

ต่อไปจะเป็นการแสดงของแต่ละคนโดยเริ่มจาก (ลำดับอาจมีผิด เพราะจำไม่ค่อยได้แล้ว เดี๋ยวจะมาแก้ถ้าทีมงานเขาลงคลิปการแสดงแล้วนะ)

น้องแพร

น้องแพรเต้นประกอบเพลงการ์ตูนสักเพลงซึ่งผมไม่รู้จัก (ฟังแต่เพลง OP & ED ของการ์ตูนยุค 2000 ) แต่เพลงก็เพราะดี น้องเต้นเก่งมากแบบไปเอาพลังงานมาจากไหน ทั้งๆที่เมื่อกี้พึ่งเต้นเสร็จ แบบยอมในความสามารถของน้องจริงๆ

น้องมุก

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

น้องบี

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

น้องแจม

น้องแจมมากับเพลงอะไรสักเพลงที่ผมก็ไม่รู้จัก แต่น้องบอกว่าเป็นเพลงลึกและไม่ค่อยมีคนฟัง ถ้าเทียบกับรุ่นผมก็คงเพลงหน้า B ของเทป ซึ่งฟังแล้วก็ลึกจริง เพลงคงจะเกี่ยวกับความโศกเศร้าบางอย่าง เดี๋ยวคงต้องไปหาฟังแล้วก็หาคำแปลว่ามันแปลว่าอะไร

น้องปิ่น

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

น้องข้าวเจ้า

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

จบ Stage

สุดท้ายน้องทุกคนก็ออกมารวมตัวพร้อมกล่าวขอบคุณทีมงานและแฟนคลับ พร้อมถ่ายรูปที่ระลึกร่วมกันด้วยสัญลักษณ์ของวง (ทำยากเกิ๊น ฮ่าๆๆๆๆๆๆๆ) รวมๆเวลาการแสดงเกือบ 2 ชั่วโมงซึ่งถือว่าเป็น 2 ชั่วโมงที่สนุกมากๆ

Meeting

หลังจากจบการ Show ส่วนต่อไปของงานคือการ Meeting ซึ่งพักประมาณ 1 ชั่วโมง ซึ่งการ Meeting ก็คือการถ่ายรูปพร้อมกับคุยกับ Member แต่ละคนคนละ 1 นาที (สั้นเกิน) จนคนครบทุกคนนั่นเอง

น้องแพร

บอกเลยว่านี่คือการคุยกับน้องแพรครั้งแรกเลย เจอคำถามแรกไปก็ช็อกเลย “พี่ไม่เคยมาเชกิกับหนูเลยใช่มะ หนูจำได้เลย” เจอช็อตนี้ไปก็ ฮ่าๆๆๆๆ แต่การพูดแบบนี้ก็แสดงว่าน้องจำคนที่มาเชกิกับน้องได้แน่นอน ก็เลยคุยกับน้องไปว่าจริงๆก็อยากถ่ายแหละแต่พี่มีงบจำกัด น้องเขาก็บอกว่าแซวเล่นแหละน้องเข้าใจ จากนั้นก็คุยกับน้องว่า พึ่งรู้ว่าน้องเต้นเป็นด้วยปกติเห็นเล่นแต่เบส แถมเต้นน่ารักด้วย น้องก็บอกว่าขอบคุณค่า สุดท้ายก็บอกน้องว่าพี่รอฟังเพลง Unit ของน้องอยู่นะ มาคิดดูก็เสียดายนะถ้าได้เชกิกับน้องนี่คงได้เชกิต่อด้วยยาวๆแน่เลย เพราะน้องคุยเก่งมาก น่ารัก ฮา แถมดีดๆด้วย

น้องมุก

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

น้องบี

นี่ก็เป็นอีกคนที่เคยคุยครั้งแรก(ในวันสุดท้ายของวงอะนะ)ซึ่งก็รู้สึกเกร็งๆเหมือนกัน ก็เลยบอกน้องว่าพึ่งรู้ว่าน้อง (ซึ่งก็ไม่รู้ว่าน้องรึเปล่า แต่น่าจะน้องแหละ อายุตัวเองใกล้ 30 ขนาดนี้ไอดอลส่วนใหญ่ก็น่าจะน้องหมดแหละ) เต้นได้เพราะเห็นแต่ยืนเล่นคีย์บอร์ด น้องก็เลยบอกว่าจริงๆเคยเต้น cover ร่วมกับน้องแพรน้องปิ่นมาก่อนแต่พอมาอยู่วงที่เล่นดนตรีเลยไม่ค่อยได้เต้น ตลอดเวลาที่คุยกับน้องนี่รู้สึกว่าบรรยากาศมันดูสบายๆ จนมาเรื่องสุดท้ายก็เลยถามน้องว่าเมื่อไหร่เพลงใหม่จะออก น้องก็เลยบอกว่าปีหน้า ก็เลยบอกน้องไปว่าจะรอติดตามเพลงใหม่นะ

น้องข้าวเจ้า

มาถึงขวัญใจของเจ้าของ Blog ซึ่งก็คือน้องข้าวเจ้าซึ่งน้องจำเราได้ด้วย (ปกติเวลาตามไอดอลเนี่ยผมจะเป็นสายจืดจาง ไม่ค่อยมีใครจำได้ ) ซึ่งสาเหตุที่น้องจำเราได้นี่เป็นอะไรที่ประทับใจมาก คือช่วงโควิดตอนนั้นนี่งานไอดอลปิดหมด ประกาศล็อกดาวน์ทั่วประเทศ วงนี้ก็เลยขายเชกิแบบออนไลน์โดยให้ใส่ชื่อตัวเองกับเรื่องที่เครียดช่วงนี้ลงไป เอาเราก็ใส่ชื่อเล่นกับภาวะหมดไฟตอนทำงานลงไป พอได้เชกิที่สั่งนี่ตกใจมากเพราะน้องดันเขียนชื่อบนเชกิว่า “พี่ปุ๋ง” ซึ่งเป็นฉายาที่เพื่อนสมัยเรียนเรียกและเราก็ไม่ได้บอกอะไรน้องไป ตอนนั้นนี่งงจัดๆแบบเฮ้ยน้องรู้ได้ไง จนงานไอดอลกลับมาจัดได้ พอได้คุยกับน้องน้องเลยบอกว่าตอนได้ Order เชกิไปน้องอยากรู้ว่าเราคือใครเลยเข้าไปหาว่าเราคือใครจนเจอเลยเข้าไปหาข้อมูลผ่านรูป Profile กับ หน้าปก เลยรู้ว่าเราเป็นใคร เรียนอะไร เพื่อนๆเรียกว่าอะไร ซึ่งน้องน่าจะต้องพยายามระดับนึงเพราะ Profile ทุกอย่างของผมเป็น Private หมด (ถึงขนาดว่าไม่ได้ใส่ว่าเรียนอะไร ทำงานที่ไหน เกิดวันไหน ชื่อบน Facebook ก็สะกดไม่ตรงกับชื่อจริงด้วย) แสดงว่าน้องต้องไล่ดูรูปกับอ่าน comment ที่เพื่อนๆผมโพสต์ทั้งหมด แต่จริงๆน้องเขาก็เป็นขวัญใจผมตั้งแต่เจอกันครั้งแรกที่งาน Idol expo ละ เพราะตอนนั้นน้องคุยเป็นกันเองมาก ตอนนั้นน้องบอกว่าไม่เคยคิดว่าตัวเองจากคนธรรมดาจะกลายเป็นไอดอล มีคนมาดู มีคนยอมเสียเงินมาถ่ายรูปด้วย แถมยังเล่นชื่อมุกชื่อข้าวเจ้าข้าวเหนียวด้วย คุยสนุกมาก พอมาถึงงานวันนี้ก็รู้สึกแปลกๆเหมือนกันเหมือนว่าจะเป็นครั้งสุดท้ายที่ได้คุยละ ก็เลยเอารูปสมัยตอนที่เชกิด้วยกันครั้งแรกให้น้องดูแล้วบอกว่า เนี่ยครั้งแรกที่เจอกันเลยนะตั้งแต่สมัยยังผมดำเลย ฮ่าๆๆๆ แล้วน้องก็คุยเรื่องเพลงที่มาร้องในงานวันนี้ว่าทำไมถึงเลือกมาร้อง ซึ่งทำให้รู้ว่าน้องเป็นที่ทำอะไรแล้วมีความหมาย เหมือนชื่อแมวของน้องนี่แต่ละตัวมีความหมายมี Story แล้วก็ได้คุยเกี่ยวกับเพลงใหม่ของน้องซึ่งก็คือเพลง My moon ว่าเพราะมากๆเลยนะ สุดท้ายเวลาก็หมดลง

น้องแจม

น้องแจมก็เป็นอีกคนที่คุยด้วยครั้งแรก ซึ่งน้องคนนี้เรานี่ไม่ค่อยเห็นเท่าไหร่ด้วยเพราะน้องตีกลองอยู่ข้างหลัง แล้วน้องไม่ค่อยพูดบนเวทีเท่าไหร่ แต่เห็นน้องสนุกกับตีกลองอยู่นะแบบ น้องจะตีมันไปไหน พอถ่ายรูปเสร็จปุ๊ปน้องนี่เปิดบทสนาอย่างพีคเลย “พี่ดูเหนื่อยๆนะคะ พักหายใจก่อนไหม หนูเห็นพี่หายใจแล้วเหนื่อยแทน หนูอยากเอาเวลาคุยไปให้พี่หายใจจริงๆ “ แบบเฮ้ยน้องนี่กันเองจริงโว้ย นานๆจะเห็นคนกันเองขนาดนี้ ซึ่งผมชอบคนที่เป็นกันเองแบบนี้ ก็เลยบอกว่าพี่หายใจไม่ทันเวลาใส่หน้ากาก แล้วก็คุยไปเรื่อย ถามว่าจะยังทำเพลงต่อไหม น้องก็บอกว่า ก็ทำนะยกเว้นช่วงสอบ ช่วงสอบนี่เหนื่อยมาก ก็เลยถามว่าอยาก skip ไปจบเลยไหม น้องก็บอกว่าอยากค่ะ พอเวลาใกล้หมดก็เลยบอกน้องว่า ไว้โอกาสหน้าเราค่อยมาคุยกันใหม่ น้องตอบอย่างจริงใจว่า “ก็คงครั้งสุดท้ายแล้วแหละพี่” เราก็บอกว่าไม่คิดว่าจะมีโอกาสเลยเหรอ น้องก็ตอบว่า “พี่ พี่คิดดูนะ ประเทศไทยมีกี่ตารางกิโลเมตร เราจะบังเอิญเจอกันอีกเหรอพี่ โอกาสมันเท่าไหร่พี่” มาคิดดูก็เออจริงของน้องนะ เราก็เลยตอบว่า ถ้ามีโอกาสเราคงได้คุยกันอีกนะ

น้องปิ่น

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

อีกรอบ

หลังจากทุกคนในงานถ่ายรูปครบเขาก็ให้เราสามารถซื้อบัตรถ่ายรูปเพิ่มได้อีกรอบ ด้วยกำลังทรัพย์ที่มีก็เลยซื้อบัตรไปคุยกับน้องสองคน

น้องข้าวเจ้า

อันนี้คุยแน่นอนอยู่ละเพราะเป็นขวัญใจ ซึ่งก็นั่งคุยเรื่องความหมายของเพลงต่อว่าเพลงที่เหลือคือเพลงอะไร น้องเลือกเพราะอะไร ซึ่งถ้าจำไม่ผิดคือเพลง I like you ของนักร้องสักคนซึ่งผมน่าจะต้องไปไล่หาเปิดต้นฉบับกับความหมายของมัน ส่วนอีกเพลงคือ never enough ของใครสักคน ซึ่งต้องบอกตามตรงว่าผมไม่สันทัดเพลงที่ไม่ใช่เพลงไทย จะฟังเพลงต่างประเทศก็เพลงพวกประกอบละคร หนัง การ์ตูน ถึงจะพอคุ้นหู ซึ่งก็มีเหตุผลว่า I like you แปลว่า หนูชอบแฟนคลับทุกคน ส่วน never enough เท่าไหร่ก็ไม่พอเหมือนความรักที่พวกเรามีให้กันประมาณนั้น สุดท้ายเวลาก็หมดลง ก็เลยบอกลาน้องว่า นี่คงเป็นครั้งสุดท้ายจริงๆแล้วนะ หวังว่าโอกาสหน้าเราจะได้คุยกันใหม่นะ น้องก็บอกว่าค่ะพี่เบล พี่ยังเป็น My Moon ของหนูนะ ตอนนั้นไม่ได้ตอบอะไรน้อง แต่จริงๆแล้วสำหรับพี่น้องก็คือ My Moon เหมือนกัน

น้องแจม

อันนี้ก็ตลกนะที่เลือกมาคุยกับน้องแจม ซึ่งก็ไม่รู้เหมือนกันว่าทำไมถึงเลือกน้องแจม คงเป็นเพราะความเป็นกันเองของน้องเขามั้ง ซึ่งก็ได้คุยกันเพิ่มเติม เปิดบทสนทนาด้วยความพีคๆของน้องคือ “คุยกับหนูชิวๆเลยพี่” ฮ่าๆๆๆ ก็เลยบอกไปว่า “พี่ชิวตลอดอยู่แล้ว” แล้วก็คุยไปเรื่อย น้องถามว่าพี่ทำงานอะไร เราก็ตอบว่าพี่เป็นโปรแกรมเมอร์เขียนโปรแกรม น้องก็บอกว่าเขียนโปรแกรมอะนะ หนูก็เคยเขียน แบบทำอะไรนะ แล้วน้องก็ทำหน้าเครียดแล้วน้องก็บอกว่า ช่างมันเถอะพี่ ฮ่าๆๆๆๆๆ แล้วก็ถามว่าพี่มาจากไหน ก็เลยบอกว่ามาจากสมุทรปราการ น้องก็บอกว่า แถวอิมพิเรียลสำโรงใช่ไหมหนูเคยไปแข่งร้องเพลงกับเพื่อน เราก็ตอบไปว่าไกลกว่านั้นอีกนะ แล้วก็คุยเรื่องเพลง My Moon ของน้องเขา ซึ่งเราก็บอกว่าเราแต่งเพลงเพราะดีนะ น้องเขาก็ยกมือกราบขอบคุณ สุดท้ายพอเวลาหมด ซึ่งมันนิดเดียวเองยังคุยไม่เสร็จเลย ก็เลยบอกน้องเขาว่า ไว้โอกาสหน้าเราค่อยคุยกันใหม่ พี่เชื่อว่าถ้าเรายังทำเพลงอยู่พี่ว่าเราคงจะได้มีโอกาสเจอกัน

จบงาน

ไม่มีงานเลี้ยงใดไม่มีวันเลิกรา คำพูดนี้ยังคงจริงเสมอ ตอนนั้นเวลาประมาณ 23.35 น. Member ก็อำลาเหล่าแฟนคลับเดินจากพวกเราไป เราแฟนคลับก็ทำได้เพียงโบกมือลาพร้อมนึกในใจว่า ถ้ามีโอกาสเราคงได้มานั่งเพลงในรูปแบบวงแบบนี้อีกนะ มาคิดเล่นๆ ถ้าค่ายนี้ยังไปต่อ มีผลงาน ไปได้เรื่อยๆ พอครบ 5 - 10 ปีเขาจัด Reunion วง Melt mallow ขึ้นมา เราก็คงไม่ลังเลที่จะจ่ายเงินไปดูอะนะ แต่มาคิดๆตอนนั้นเราน่าจะอายุเกือบ 40 แล้ว น้องๆก็อายุ 30 - 35 กันแล้ว เขาจะกลับมาไหมนะ ช่างเถอะมันเป็นเรื่องของอนาคต แต่พอพูดถึงอนาคตก็ย่อมนึกถึงอดีต มาคิดๆดูก็เสียดายนะ มีอีกหลายงานที่เราไม่ได้ไปดูน้องๆแสดง ไม่ได้เชกิกับน้องบางคน เลยไม่รู้ว่าจริงๆแล้วน้องๆคุยสนุกแค่ไหน ไม่ว่าจะน้องแจม น้องบี น้องแพร เสียดายจริงๆ จนนึกถึงคำพูดเพื่อนคนนึงที่พูดว่า “ช่วงเวลาของไอดอลมันสั้นอยากทำอะไรก็รีบๆ ทำก่อนที่จะไม่มีโอกาส” ขึ้นมา อือ มันสั้นจริงๆนั่นแหละปีกว่าๆเอง เรื่องนี้สอนให้รู้ว่าหาเงินเยอะๆจะได้มีเงินไปถ่ายเชกิกับไอดอล (ถ้าย้ายงานไปที่เดียวกับเพื่อนแล้วเงินเดือนใกล้ๆมัน ตอนนี้คงได้สนับสนุนวงเยอะกว่านี้แล้วอะนะ)

ตื่นจากฝัน

งานจบก็เหมือนตื่นจากความฝัน เราต้องไปเข้าวังวนชีวิตเดิมๆงานน่าเบื่อๆ คุยกับคนน่าเบื่อๆ ทำงานในสิ่งที่ไม่รู้ว่าเราชอบหรือเปล่า ผมอาจชอบเขียนโปรแกรมแต่พอมาเป็นงานความชอบเมื่อตอนที่เขียนครั้งแรกมันหายไปแล้ว จริงๆก็มีอย่างอื่นที่ ชอบแต่ทำแล้วไม่ได้เรื่องเลยเลิกทำไป กลบไปใช้ชีวิตเป็น Loop ต่อไป ผมไม่รู้ว่าตอนนี้มีความสุขไหม ไม่รู้ว่าทุกข์ไหม ทุกวันเหมือนเดิม ทุกวันยังตามหาความหมายของชีวิต ตามหาสิ่งที่อยากทำอยากเป็นไปเรื่อยๆ ไม่มีวันสิ้นสุด แต่อย่างน้อยถ้าวันไหนเหงา เศร้า หรือท้อใจ ก็ยังมีความทรงจำดีๆ เพลงเพราะๆ ของวงนี้ลดความรู้สึกแย่ๆลงไปได้ สุดท้ายก็มีนึกถึงคำพูดน้องๆที่พูดไว้ว่า “ถ้าคิดถึงวงนี้ก็ขอให้เปิดเพลงของพวกเราฟังนะ”

เถื่อน8

หนังสือจากคนที่ชอบ

เถื่อน8

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

ทำไมชื่อคุ้นๆ

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

การเดินทาง

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

คำถาม

หนังสือเล่มนี้นอกจากจะพาเราไปเที่ยวมีภาพสวยๆในเล่มแล้วยังมีคำถามมากมายที่พี่สิงห์แกตั้งคำถามมากมายเกี่ยวกับที่เกี่ยวกับที่ที่แกไปเที่ยว เช่น เราอคติกับประเทศที่ชื่อ เกาหลีเหนือ รึเปล่า อคติเหล่านั้นจะจางลงเมื่อไปเกาหลีเหนือหรือไม่ คนเกาหลีเหนือนั้นอยู่กันแบบไหน เขาเต็มใจที่จะรักชาติแบบนั้นหรือจริงๆนั้นถูกบังคับ หรือ ญี่ปุ่นประเทศที่เปิดกว้างเรื่อง sex นั้น คนเหล่านั้นมอง sex แบบไหน การถ่ายหนัง AV นั้นมีขั้นตอนยังไง ทำยังไง ดาราที่มาเล่นนั้นเขาเต็มใจไหม ทำไมถึงมา คิวบาดินแดนที่น้าเช (เช เกบารา) คือวีรบุรุษ ได้รู้เกี่ยวกับน้าเชที่เราเห็นหลังรถบรรทุกว่าเขาคือใคร ทำไมคนถึงบูชาเขา แต่เมื่อเราอ่านแล้วเราควรบูชาเขาจริงรึเปล่า คำถามมากมายเหล่านี้จะถูกถามทำให้เราไม่เบื่อแถมบางครั้งก็ทำให้เราได้เห็นการมองโลกในมุมที่เราไม่เคยคิดถึง

อ่านแล้วได้อะไร

สำหรับผมการอ่านหนังสือเล่มนี้ทำให้ผมได้เห็นโลกมากขึ้น (ถึงจะไม่ได้เองก็เถอะ) ได้ความรู้ใหม่ๆ ได้รู้ว่าหนัง AV เขามีขั้นตอนการผลิตยังไง ที่ที่วัวคือทุกสิ่งตั้งแต่ยาโด๊บ อาหาร บ้าน รองเท้า สกุลเงิน สมบัติ น้าเชที่เราเห็นท้ายรถบรรทุกคือใคร เป็นคนที่น่าสรรเสริญหรือคนที่น่าสาปแช่ง รู้ว่าเทือกเขาคิลิมันจาโรนั่นเป็นหนึ่งในเจ็ดผู้เขาที่สูงที่สุดในโลก แถมยังขึ้นง่ายที่สุดใน 7 ลูกนั้น

Concurrency Part 3 - ปัญหา Phantom และ อธิบายเกี่ยวกับ Isolation level เพิ่มเติม

Concurrency Part 3 : ปัญหา Phantom และ อธิบายเกี่ยวกับ Isolation level เพิ่มเติม

ผมเขียนเกี่ยวกับ Concurrency ไว้หลายตอน คุณสามารถกด Link ด้านล่างเพื่ออ่านที่เกี่ยวกับ Concurrency ตอนต่างๆได้เลย

ตอนที่แล้วเราได้เรียนรู้ Isolation level ทั้ง 4 ระดับแล้วก็มีติดกันเรื่องปัญหา Phantom ว่าคืออะไร ตอนนี้เราจะมาอธิบายว่าปัญหา Phantom คืออะไร แล้วก็อธิบายว่าทำไม Isolation level นี้ถึงแก้ปัญหาแต่ละปัญหาได้ เพราะตอนที่แล้วไม่ได้อธิบาย

Phantom

ในตอนก่อนเวลาเราพูดถึงปัญหาเราจะมองว่าปัญหาเกิดขึ้นกับ field บน Row ที่มีอยู่ในระบบ และเรามักจะสนใจที่ Row ที่เราสนใจ จนเรามองข้ามปัญหานึงไปนั่นก็คือปัญหา Phantom นั้นเอง ลองนึกภาพตามที่เรา Query ข้อมูลหลายๆ Row ว่าง่ายคือ WHERE เป็น Range นั่นเอง คราวนี้มีการสั่ง Insert ข้อมูลเข้าไปในระบบ อะไรจะเกิดขึ้นเพราะ Row ที่ Insert เข้าไปเป็น Row ใหม่ ไม่เคยมีอยู่จริง คราวนี้ก็เกิดปัญหาสิ

ภาพจาก Wikipedia

รอบนี้ขี้เกียจทำรูปละเหนื่อยเกินเลยขอใช้รูปจาก Wikipedia แทน ซึ่งถ้าเราอยากจะการันตีไม่ให้เกิดปัญหานี้เราแค่กำหนด Isolation level เป็นระดับ Serializable ซะก็จะสามารถแก้ปัญหานี้ได้

แล้วใช้ Isolation level อะไรดีล่ะ

ถ้าอยาก Play safe สุดก็ตั้งระดับเป็น Serializable หมดเลยก็จบเลยสิ ซึ่งจริงๆมันก็เป็นคำตอบที่ถูกครับ แต่โดยภาพรวมระบบอาจทำงานช้าลงเพราะการทำ Serializable มันต้องทำงานเสมือนว่า Transaction ที่เข้ามาต้องเสมือนว่าทำงานต่อกัน ที่ใช้คำว่าเสมือนเพราะเขาสนที่ผลลัพธ์ว่าผลลัพธ์หลังจากการทำงานแล้วผลลัพธ์เหมือนกันไหม แต่โดยการเช็คนั้นก็วิธีการเช็คที่กินเวลาอยู่ ดังนั้นหากการเลือกใช้ระดับ Isolation level ให้เหมาะกับงานน่าจะตอบโจทย์กว่า

Read Uncommited

เฮ้ยงานไหนมันจะใช้ Read Uncommited วะ อ่านข้อมูลที่ยังไม่ Commit ซึ่งสำหรับงานที่ทำมันหายากมาก แต่เคยที่เจอคืองาน Gen Ref คือมันมีคน Design วิธี Gen ref หลายๆ Ref โดยใช้ตารางเดียวกัน คือถ้ามันมี Ref เดียวตารางเดียวมันจะง่ายมากโดยการใช้ Auto increment ในการบอกว่ามันคือ Ref เท่าไหร่ แต่คราวนี้พอใช้ตารางเดียวกันมันใช้ Auto increment ไม่ได้ คราวนี้ก็ต้องมาใช้การนับว่า Ref ที่ต้องการมันมีไปกี่อันแล้วนั่นเอง

อันนี้ตัวอย่างตารางมีข้อมูลประมาณนี้ อ่านถึงตรงนี้เหมือนไม่มีปัญหาอะไรใช่ไหมครับ คราวนี้ลองนึกภาพตามว่ามี Request รัวๆเข้ามาแล้วต้องใช้ table นี้ในการ gen ref สภาพจะเป็นประมาณนี้

step การทำงานก็จะประมาณว่า

1
INSERT INTO tab_gen_ref (refType) VALUES ('A')

เมื่อ insert เสร็จเราจะได้ auto increment นั้นมา จากนั้นเราจะ Count จำนวนตัวเลข ref ที่เราต้องการจากใช้คำสั่ง

1
2
-- x คือ id auto increment ที่เรา insert ลงไปเมื่อกี้
SELECT COUNT(*) FROM tab_gen_ref WHERE id < x

ซึ่งถ้าจำลองการทำงานมันจะได้ดังภาพด้านล่าง

ซึ่งเราจะเห็นว่าถ้าเราใช้ Isolation level ระดับ Read commited จะเกิดปัญหาเพราะเขาไม่อ่านข้อมูลที่ยังไม่ commit จำนวนที่ count ได้มันเลยไม่ได้อย่างที่ต้องการ แต่ถ้าเราใช้ Read Uncommited จะสามารถอ่านข้อมูลที่ไม่ commit ได้ทำให้ผลลัพธ์ได้อย่างที่เราต้องการ

Read Commited

มาถึง Read commited อันนี้เป็นระดับที่ใช้บ่อยระดับ สำหรับระดับนี้ตอนที่ผมทำงานก็จะเป็นงานประมาณว่า อ่านไปใช้อย่างเดียวไม่ได้มีผลกับการเอาไปทำอย่างอื่น เช่น ดึงเอาไปออกฟอร์มบางอย่าง โดยฟอร์มนั้นอ้างอิงตามเวลานั้น ไม่ได้สนใจว่าหลังจากดึงข้อมูลจะเปลี่ยนหรือไม่ประมาณนั้น

Repeatable reads

สำหรับระดับนี้เป็นระดับที่ผมใช้บ่อยสุดเพราะต้องการป้องกันปัญหา Lost update เลยมาใช้ระดับนี้ เพราะงานที่ผมทำส่วนใหญ่จะเป็นการทำการ Update ข้อมูล ดังนั้นเวลา select ข้อมูล row นึงขึ้นมาเพื่อทำการ update อาจมีอีกคนพยายามดึงข้อมูลไป Update หรือกำลังอยู่ในการ Update เนื่องจากไม่อยากให้อยู่ในสถานการณ์แบบนั้นผมเลยเลือกใช้ Isolation level นี้

Serializable

ส่วนอันนี้ผมไม่เคยมีโอกาสได้ใช้งานจริงๆเลยเพราะยังไม่ค่อยเจองานไหนใช้ Isolation ระดับนี้เพราะมันเข้มสุด แต่จริงๆก็มีงานที่เคยคิดว่าอาจจะต้องใช้แน่ๆคือออก Report แบบที่ต้องการความแน่นอนมากๆ ประมาณว่าเชื่อข้อมูลตอน Report นั้นออกมา (Transaction commit แล้ว) พูดตรงนี้อาจจะงงนิดหน่อยเรามาอธิบายด้วยรูปภาพ

ถ้าเทียบกันจะประมาณว่าถ้าใช้ Repeatable reads นั้นเราจะเชื่อข้อมูลตอนที่ดึงครั้งแรกเท่านั้นเพราะถ้ามีการ insert ข้อมูลเข้าไปก็จะไม่มีอะไรเกิดขึ้น (ระดับนี้ไม่กัน Phantom) แล้วการทำงานก็จบลง

ถ้าโจทย์ของการออก Report นี้คือจะเชื่อ Report ตอนออกเสร็จ ระดับ Repeatable read จะไม่ตอบโจทย์เพราะตอน Commit นั้นมีการ insert ข้อมูลไปก่อน แต่ถ้าอยากจะเป็นตามโจทย์ก็ต้องใช้ Serializable เพราะระดับนี้จะการันตีไม่เกิด Phantom ดังภาพ ซึ่งจะเกิดได้สองกรณีแล้วแต่การ Implement ของ DBMS

หมดละเรื่องนี้

สำหรับเรื่องเกี่ยวกับ Concurrent นั้นผมคงจะหมดเรื่องที่เล่าให้ฟังละ และด้วยเนื้อหาทั้ง 3 ตอนก็น่าจะพอช่วยให้โปรแกรมเมอร์น้องใหม่หลายๆคนที่หลงเข้ามาอ่านพอจะเห็นภาพว่ามันมีปัญหา Concurrent อะไรเกิดขึ้นบ้างแล้วถ้าสมมุติใช้ RDBMS แล้วล่ะจะใช้ Isolation level อะไรในการแก้ปัญหา ในส่วนของตอนถัดไปนั้นผมอาจจะมาเขียนเกี่ยวกับเรื่องการทำ Transaction ระหว่าง Application หรือ ทำ Transaction ระหว่าง Microservice

Reference

https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-95-51.pdf

https://onlinelibrary.wiley.com/doi/abs/10.1002/(SICI)1097-024X(199801)28:1%3C77::AID-SPE148%3E3.0.CO;2-R

https://en.wikipedia.org/wiki/Isolation_(database_systems)

เพลงประกอบการเขียน Blog

เพลงนี้เป็นเพลงใหม่ของวง Meltmallow แต่น่าเสียดายที่วงจะปิดตัวลงในสิ้นปีนี้ ผมชอบวงนี้มากเลยนะเพราะเขาทำเพลงได้ดีทุกเพลงเลย โดยเพลงนีชื่อ My moon ซึ่งเนื้อเพลงมีความหมายดีมาก ดนตรีเศร้าๆ ฟังแล้วนึกถึงใครสักคนที่มีความหมายกับเรา

Concurrency Part 2 - Transaction , ACID และ Isolation level ของ Relational Database

Concurrency Part 2 : Transaction , ACID และ Isolation level ของ Relational Database

ผมเขียนเกี่ยวกับ Concurrency ไว้หลายตอน คุณสามารถกด Link ด้านล่างเพื่ออ่านที่เกี่ยวกับ Concurrency ตอนต่างๆได้เลย

ตอนที่แล้วเราพูดถึงเรื่องปัญหาการใช้ Database พร้อมกันจากหลาย Process (Thread, Request) ซึ่งทำให้เกิดปัญหา Lost update, Dirty read, Non repeatable read ซึ่งจริงๆมีอีกหลายตัว แต่พูดตัวที่เห็นง่ายๆก่อน ในตอนนี้เรามารู้จักกับศัพท์ที่จะได้ยินบ่อยต่อจากนี้ และจะเจอบ่อยเวลาทำงาน

Transaction

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

ถ้าสมมุติเราจะโอนเงินจากบัญชี A จำนวนเงิน 100 ไปบัญชี B การทำงานจะเป็นดังภาพด้านซ้าย แต่นั่นคือกรณีที่เราโชคดีครับโลกมียังมีเรื่องโชคร้ายอีกเยอะแยะที่จะเกิดขึ้น (จริงๆไม่ใช่โชคร้ายอาจเป็นเหตุการณ์บางอย่างที่มันเกิดขึ้นได้แล้วพอมันเกิดขึ้นแล้วไม่ส่งผลดีต่อเราเราเลยบอกว่ามันเป็นโชคร้าย) ในภาพด้านขวานั้นเกิด Database ดับไปซึ่งนั่นแปลว่าเงินที่ต้องไปเพิ่มในบัญชี B นั้นหายไปซึ่งจะทำยังไงต่อล่ะ คนเขียน App จะต้องทำยังไงต้องเก็บข้อมูลไว้ก่อนเหรอ แล้วจะรู้เหรอว่า Database ทำงานไปถึงไหนแล้ว

ด้วยปัญหานี้ที่เกิดขึ้นจึงมีการนิยาม Transaction ขึ้นมาเพื่อให้คนเขียน Database อ่าเรียกมันว่า DBMS (Database Management System) จัดการปัญหานี้ให้กับผู้ใช้งาน DBMS สามารถใช้งานได้โดยไม่ต้องหาวิธีมาจัดการปัญหานี้ ซึ่งโชคดีที่ RDBMS ส่วนใหญ่ดังๆในตอนนี้เช่น MySQL, MariamDB, SQLServer, Oracle, Ibm Db2 รองรับการมี Transaction นี้

คำถาม : อ้าวแล้วที่เรา Update กันอยู่นี้มันเป็น Transaction ไหม

คำตอบคือเป็นจ้า คือถ้าเราสั่ง Update คำสั่งเดียวๆเฉยๆนั้นก็เป็น Transaction เพราะ DBMS จะเข้าใจว่าทุกการเปลี่ยนแปลง DBMS เป็น Transaction ดังนั้นตัวอย่างด้านบน DBMS ไม่ถือว่าทำงานผิดนะเพราะเขาถือว่า Update Account A เป็น 1 transaction แล้วมันทำงานสำเร็จมันก่อน DBMS ดับ ดังนั้นมันถือว่า DBMS ไปอยู่ใน state ที่ถูกต้องแล้ว ตรงนี้อยากอธิบายให้เข้าใจว่า DBMS เขาไม่รู้ว่า Logic ว่าต้อง Update Account B ก่อนถึงจะถูกต้องตามกฏ

คำถาม : แล้วจะทำ Transaction กับหลายๆคำสั่งยังไง แล้วเราจะบอกให้ DBMS ว่า Transaction มันสำเร็จหรือไม่สำเร็จ

คำตอบคือ แค่สั่งเองจ้าตัวคนเขียน DBMS เขากำหนดคำสั่งให้เราแล้วโดยคำสั่งที่ว่านั้น Begin , Commit , Abort (บาง DBMS อาจเรียกแตกต่างกันเช่น Begin บางที่เรียก Set auto commit off , Abort เรียก Rollback)

ดังนั้นการสั่งโอนเงินของเราจากภาพเราต้องสั่งเป็นดังภาพ คือเราจะบอกกับ DBMS ก่อนว่าคำสั่งอะไรต่างๆต่อนี้จะเป็น Transaction นะ เมื่อ DBMS ทราบจากนั้นเราสั่งคำสั่ง SQL ต่อจากนั้นจะถือว่าเป็น Transaction ทั้งหมด

กรณีทุกอย่างทำงานถูกต้อง (ภาพด้านซ้าย)

ถ้าทุกอย่างทำงานได้อย่างถูกต้องแล้วเราอยากบอกให้ DBMS ทราบว่าเรายืนยันว่า Transaction นี้ทำงานถูกต้อง เราแค่สั่ง Commit ไปที่ DBMS เมื่อสั่งไปที่ DBMS ตัว DBMS จะมีวิธีการทำงานบางอย่างเพื่อให้ข้อมูลมันคงอยู่ (เขามีวิธีของเขา ซึ่งมีหลากหลายวิธี แต่ละวิธีมีความเร็วความช้าไม่เหมือนกัน ) ซึ่งถ้า DBMS ตอบกลับมาว่าสำเร็จ ขอให้เราเชื่อใจได้เลยว่าข้อมูลจะถูกบันทึกไว้แล้ว แม้ว่า DBMS จะดับไปหลังจากได้รับตอบกลับแค่ 1 ns หลังจากนั้น (ยกเว้นที่เก็บข้อมูล Database จะระเบิดแล้วไม่ได้ทำ Stable storage ไว้)

กรณี DBMS ดับไปแล้วไม่ได้ Commit (ภาพด้านขวา)

ในกรณีนี้ไม่มีอะไรมากครับถ้าเราไม่ได้ Commit แล้วตัว DBMS เกิดดับเมื่อ Start ตัว DBMS ขึ้นมาตัว DBMS จะมีวิธีจัดการของเขาเองแล้วเขารับประกันว่าอะไรข้อมูลของเราที่ถูกเก็บไว้จะไปอยู่ใน state ก่อนเริ่ม Transaction

กรณีเราอยากยกเลิก Transaction (ภาพตรงกลาง)

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

ACID คืออะไรล่ะ

ACID คือคุณสมบัติของ Transaction นั่นเองโดย ACID เป็นคำย่อตามภาพ (จริงๆมีคำอธิบายในภาพแล้ว)

ภาพจากเว็บ https://www.geeksforgeeks.org/acid-properties-in-dbms/

Atomicity

คือเป็นอันหนึ่งเดียวกันประมาณว่าทุกคำสั่งใน Transaction จะเสมือนว่าเป็นคำสั่งเดียว ถ้าสำเร็จ (commit) คือสำเร็จทั้งหมด ถ้าไม่สำเร็จ (abort) คือไม่สำเร็จทั้งหมด

Consistency

คือความถูกต้อง ถ้า Transaction ถูกสั่งให้ Commit จะถือว่าที่สั่งคำสั่งทั้งหมดใน Tranaction ทำงานสำเร็จ (ย้ายจาก state นึงไปอีก state นึงเรียบร้อย) แต่ถ้า Transaction ถูกสั่งให้ Abort หรือ DBMS เกิดปัญหาก่อน Commit ทุกสิ่งที่ทำใน Transaction จะต้องเหมือนไม่เกิดขึ้น (ข้อมูลจะต้องกลับไปอยู่ใน state )

Isolation

อันนี้คือ…. แปลยากจริงๆ อันนี้คือความโดดเดี่ยว ประมาณว่า Transaction จะต้องทำงานโดยเสมือนว่าไม่มีอีก Transaction นึงทำงานอยู่อันนี้คือการทำงานที่ดีที่สุดซึ่งระดับความโดดเดี่ยวนั้นมีหลายระดับ (ก็เหมือนความเหงาที่มีหลายระดับเหมือนกัน) ซึ่งโดยทางปฏิบัตินั้นการกำหนด Isolation ไว้สูงนั้นจะลด Throughput ของระบบลง ดังนั้นการเลือกระดับ Isolation ก็มีความสำคัญเช่นกัน

Durability

คือความคงทน อันนี้ก็จะประมาณว่าถ้าสั่ง Commit ไปแล้ว ข้อมูลจะต้องถูกบันทึกแน่นอนไม่ว่าจะยังไงก็แล้วแต่

Isolation level

Isolation level คือระดับความโดดเดี่ยว (ยังกะความเหงา) ของ Transaction โดยใน Relational Database นั้นได้กำหนดมาตรฐานของ Isolation level ไว้ใน The ANSI/ISO standard SQL 92 ซึ่งมี 4 ระดับคือ

  1. Read uncommitted
  2. Read committed
  3. Repeatable reads
  4. Serializable

ก่อนจะพูดกันต่อนั้น ระดับของ Isolation level มันแค่บอกว่าต้องทำอะไรได้ถึงจะอยู่ในระดับ Isolation level นี้ได้ ไม่ได้บอกวิธีการ Implement ว่าต้อง Implement ยังไง อันนี้แล้วแต่ผู้พัฒนา DBMS เลยว่าจะทำยังไง ดังนั้นผมจะไม่พูดวิธี Implement ของมันละกัน (เพราะผมก็ไม่รู้ว่าจริงๆเขาทำกันแบบไหน)

Read uncommitted

Isolation level นี้ระดับนี้ก็ตามชื่อเลยครับคือสามารถอ่านข้อมูลที่ Transaction อื่นยังไม่ Commit ได้ซึ่งดูได้จากภาพ จะเห็นว่า Transaction ที่ 2 สามารถอ่านค่า Transaction ที่ 1 ได้แม้จะ Transaction ที่ 1 ยังไม่ Commit

Read committed

Isolation level นี้ก็ตามชื่ออีกเช่นกัน (ก็ไม่รู้จะอธิบายทำไม ฮ่าๆๆๆๆ) ก็คือ Transaction ที่อยู่ใน Isolation นี้จะอ่านได้เฉพาะค่าที่ commit แล้วเท่านั้น อะไรที่ยังไม่ commit จะไม่เห็น

พออ่านมาถึงตรงนี้ก็อ้าวเฮ้ยภาพข้างบนมันทำงานผิดนี่ ไม่ต้องตกใจครับ Isolation level แค่บอกเฉยๆว่าทำอะไรได้ ดังนั้นมันจึงไม่แปลกที่จะเกิดปัญหา

Repeatable reads

Isolation level นี้ก็ตามชื่ออีกเช่นกัน (เริ่มกำหมัดแล้วสินะ คือจริงๆคนตั้งชื่อ level เขาตั้งได้ดีมากกว่า) ก็คือ Transaction ที่อยู่ใน Isolation นี้จะอ่านค่าที่ Commit แล้วเท่านั้นและต้องได้ค่าเดิมเสมอ หรืออะไรที่ตัวเองทำการแก้ไขไปแล้ว (แม้จะไม่ได้อ่านก็ตาม) ซึ่งจากภาพจะเห็นว่าถ้าจะใช้รูปแบบการเข้ามาของข้อมูลเหมือนเดิมจะเกิดขึ้นได้สองกรณีคือ Tx1 (ย่อมาจาก Transaction 1) สามารถ Commit ได้ส่วน Tx2 Abort ได้ หรือ อีกกรณีนึง Tx2 สามารถ Commit Tx1 Abort (ขึ้นอยู่กับ DBMS เขา Implement ยังไง) ซึ่งที่เป็นอย่างงี้เพราะ Transaction ทั้ง 2 ตัวต่างขอ Isolation level เป็น Repeatable reads ดังนั้นเมื่อมีใครสักพยายามเขียนค่าแล้ว commit ซึ่งมันไปขัดกับหลักการที่ว่า Tx ต้องอ่านแล้วได้ค่าเดิมเสมอ ดังนั้นต้องมีใครคนใดคนหนึ่งต้องถูก Abort เพื่อรักษาความเป็น Repeatable read

Serializable

ระดับนี้อธิบายยากสุดละ แต่ถ้าบอกว่ามันเข้าใจง่ายไหมก็เข้าใจได้ไหมก็ได้ ก็ไม่มีอะไรมาก ถ้า Transaction ที่กระทำในระบบแล้วได้ข้อมูลเหมือนการทำเป็น Serial transaction นั้นถือว่าถูกต้อง อย่างเช่นดังภาพ ถ้า Transaction ที่ทำงานแล้วผลลัพธ์ที่ออกมาทำงานแล้วได้ผลลัพธ์เหมือนดังภาพจะถือว่าเป็น Serialrizable

Isolation level แต่ละอันแก้ปัญหาอะไรได้บ้าง

ภาพจาก wikipedia

อันนี้มาถึงจุดสุดท้ายละคือจริงๆที่เล่ามาทั้งหมดเนี่ย ถ้าจะเอาไปใช้งานแบบโอเคกลัวว่าจะเกิดปัญหานี้ก็ใช้ Isolation Level นี้ไปเลยจะได้ไม่ต้องกลัวเกิดปัญหาอ่านแค่ส่วนนี้ส่วนเดียวตอบโจทย์ (ผมเลยเอามาไว้ล่าสุดยังไงล่ะ) ก็ถ้าสมมุติงานของเราอยากอ่านข้อมูลในระดับที่ Commit แล้วในช่วงเวลาที่กด ไม่ได้สนใจว่าหลังจากนั้นจะมีการแก้ไขไหม อันนี้เราสามารถใช้ Isolation level ระดับ Read commited ได้ งานพวกนี้ก็เช่น Report ย้อนหลัง แต่ถ้าเป็นงานพวกที่ให้ระดับความสำคัญมากๆ อาจเพิ่มเป็น Isolation level ระดับ Repeatable reads แทน

ตัดจบแค่นี้ก่อน

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

Reference

https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-95-51.pdf

https://onlinelibrary.wiley.com/doi/abs/10.1002/(SICI)1097-024X(199801)28:1%3C77::AID-SPE148%3E3.0.CO;2-R

https://www.geeksforgeeks.org/acid-properties-in-dbms/

https://en.wikipedia.org/wiki/Isolation_(database_systems)

เพลงประกอบการเขียน Blog

Concurrency Part 1 - ปัญหาพื้นฐานเมื่อใช้งาน Database พร้อมกัน

Concurrency Part 1 : ปัญหาพื้นฐานเมื่อใช้งาน Database พร้อมกัน

ผมเขียนเกี่ยวกับ Concurrency ไว้หลายตอน คุณสามารถกด Link ด้านล่างเพื่ออ่านที่เกี่ยวกับ Concurrency ตอนต่างๆได้เลย

ปัญหาการใช้ Database พร้อมกันจากหลาย Process (หรือหลาย Thread หลาย Request เอาเป็นว่าเข้ามาใช้งานพร้อมๆกัน) เป็นปัญหาพื้นฐานที่ Programmer ทุกคนน่าจะเคยเจอ (จริงๆมันไม่ใช่เฉพาะ Database แต่มันเป็นปัญหาในการใช้งาน Resource พร้อมกัน) แต่ต่อให้เป็นปัญหาพื้นฐานแต่การพูดถึงเรื่องนี้นี่น้อยมาก เด็กจบใหม่หลายคนไม่ค่อยรู้เรื่องนี้ (เขาจบใหม่อะนะ) แล้วต้องมาทนทุกข์ทรมาณเวลาเจอปัญหาเหล่านี้ (เขียนเกือบเสร็จแล้วค่อยมารู้) บทความนี้เลยอยากพูดถึงเรื่องนี้เพื่อให้เกิดการตระหนักรู้เกี่ยวกับปัญหานี้ เวลาเขียนโปรแกรมจะได้ Design โปรแกรมให้ป้องกันปัญหานี้

ปัญหา Lost update

สมมุติกรณีเป็น

Process A ต้องการหักเงินจากบัญชีของคุณเป็นจำนวนเงิน 100 บาท

Process B ต้องการหักเงินจากบัญชีของคุณเป็นจำนวนเงิน 200 บาท

เงินในบัญชีคือ 500

ปัญหาแรกที่เราจะพูดถึงคือ Lost update Problem ตัวอย่างคือ Process A อ่านค่าเงินออกไป 500 คำนวนแล้วจะต้องบันทึกข้อมูลไปเป็นจำนวน 400 ส่วน Process B ก็อ่านเงินออกไป 500 ไปคำนวนแล้วต้องบันทึกเป็นเงิน 300 ลง Database จะเห็นว่า Process B ทำการบันทึกค่าจากนั้น Process A ทำการบันทึกค่าจะเห็นว่าการบันทึกค่าของ Process B หายไปเหลือแต่การบันทึกค่าของ Process A (ซึ่งก็ไม่ถูกอยู่ดี)

ปัญหา Dirty Read

สมมุติกรณีเป็น

Process A เป็นงาน Batch ทำการตัดเงินจากบัญชีหลายรายการโดยตัด 2 รายการ รายการแรก 100 รายการที่สอง 100
Process B ดึงข้อมูลเงินในบัญชีออกไปเพื่อไปแสดงผลให้ลูกค้าดู

เงินในบัญชีคือ 500

ปัญหาต่อมาคือ Dirty Read ว่าง่ายๆคือเรากำลังอ่านข้อมูลที่ยังไม่สมบูรณ์ ถ้าในตัวอย่างคือ Process A กำลังทำงาน Batch ตัดเงินในบัญชีอยู่ ระหว่างที่กำลังตัดรายการแรกเสร็จ ตัว Process B เข้ามาทำการอ่านข้อมูลไปแสดงผลว่าบัญชีมีเงินอยู่เท่าไหร่ เพื่อเอาไปใช้ในงานสำคัญบางประการ ซึ่งเข้ามาอ่านตอนที่ Process A ยังทำงานไม่เสร็จทำให้อ่านข้อมูลที่ยังไม่เสร็จไป

ปัญหา Non Repeatable Read

สมมุติกรณีเป็น

Process A อ่านข้อมูลทุกบัญชีในธนาคารเพื่อ Sum ยอดรวมออก Report

Process B ต้องการหักเงินจากบัญชีของคุณเป็นจำนวนเงิน 200 บาท

เงินในบัญชีคือ 500

ปัญหาต่อมาจะพูดกันคือ Non Repeatable Read ว่าง่ายๆคืออ่านถ้าอ่านข้อมูลสองรอบแล้วได้ค่าไม่เท่ากัน (คาดหวังว่าจะอ่านทุกครั้งแล้วได้ค่าเหมือนเดิม แม้จะไม่เข้าไปอ่านก็ตาม) ดังตัวอย่างในภาพ Process A ดึงข้อมูลทุกบัญชีเพื่อไปออก Report ในระหว่างนั้นมี Process B เข้ามาทำการเขียนข้อมูลลงใน Account X ทำให้ค่าเงินมันเปลี่ยนไปส่งผลให้รายงานที่ออกมีข้อมูลไม่ถูกต้อง (จริงๆปัญหา Lost update อันแรกก็เกิดจาก Non Repeatable Read เหมือนกัน)

วิธีแก้นั้นมีแล้ว ง่ายมากๆ ใช้ Lock ไงล่ะ

วิธีการแก้ปัญหาพวกนี้นั้นมีอยู่แล้วครับ ไม่ยากด้วย (แต่ดีรึเปล่าอีกเรื่อง) วิธีแก้ปัญหาเหล่านั้นก็คือ Lock ข้อมูลที่จะใช้เลยจ้า ตัวอย่างเช่น ถ้าเราต้องการจะ Update ข้อมูลบัญชี X เราก็ Lock บัญชี X ไปเลย เราจะเป็นคนเดียวที่ใช้บัญชี X ได้ คนอื่นที่จะมาใช้งานจะต้องรอจนกว่าเราใช้เสร็จถึงจะเข้าไปงานบัญชี X ได้ดังตัวอย่าง Lost update ถ้าเราใช้ Lock ช่วยก็การทำงานจะเป็นดังภาพด้านล่าง ซึ่งผลลัพธ์ที่ออกมานั้นถูกต้อง

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

แล้วจะแก้ไงล่ะ ก็เพิ่มระดับ Lock ไงล่ะคุณผู้ชม โดยเราจะทำการสร้าง Lock ขึ้นมา 2 แบบคือ

  1. Read lock (บางที่เรียก Share lock)

    ตัว Read lock จะทำการ Lock แต่มีเงื่อนไขว่าถ้าคนที่ขอใช้ข้อมูลที่ Lock อยู่เนี่ยขอแบบ Read Lock เหมือนกันก็จะยอมให้ใช้งาน (มันเลยมีบางที่เรียกว่า Share lock เพราะมัน Share กันได้) แต่ถ้าขอแบบ Write Lock จะไม่ยอมให้ใช้ข้อมูล ส่วนใหญ่การขอ Read lock จะขอเมื่อต้องการอ่านข้อมูลเฉยๆไม่อยากแก้ไข

  2. Write lock (บางที่เรียก Exclusive lock)

    ตัว Write lock จะทำการ Lock ข้อมูลแบบให้ใช้ได้แค่คนที่ขอเท่านั้น ใครมาขอใช้ Lock แบบไหนจะไม่ยอมให้เลย ส่วนใหญ่การขอ Write lock จะขอเมื่อต้องการแก้ไขข้อมูลนั้น

ดังนั้นปัญหาการ Export Report ด้านบนก็จะถูกแก้ด้วยการใช้ Read lock ในการดึงข้อมูลนั่นเอง

การจัดการด้วย Lock มันเหมือนง่ายแต่ยากนะ

ในตัวอย่างที่ผ่านๆมาการ Lock นั้นเข้าถึงข้อมูลตัวเดียว และ Process ที่เข้ามาใช้งานมีแค่ 2 Process แต่ถ้า Process ที่เข้ามาใช้งานมีหลายตัวและเข้าถึงข้อมูลหลายตัวเช่นกัน แล้วปัญหาแรกๆที่เราจะเจอเมื่อใช้ Lock คือ Dead lock ซึ่งก็คือสถานะไปต่อไปไม่ได้โดยปัญหาที่แสดงการเกิด Dead lock ได้ง่ายที่สุดคือ

Dining philosophers problem

โจทย์นี้ไม่มีอะไรมากเลยคือ นักปราชญ์มานั่งล้อมวงคิดงานสำคัญกัน แต่ถ้านั่งคิดอย่างเดียวก็กลัวจะหิวเลยวางมีของกินวางไว้ด้วย แต่กลัวนักปราชญ์จะกินอย่างเดียวก็เลยว่างส้อมไว้แค่ 5 คัน โดยจะกินอาหารได้ต้องใช้ส้อม 2 คันเท่านั้น และด้วยความที่กลัวจะเขินเวลาหยิบส้อมมาจะกินอาหาร นักปราชญ์ก็เลยตั้งกฏขึ้นมาว่าถ้าหยิบส้อมขึ้นมาแล้วต้องได้กินอาหารถึงจะวางส้อมได้

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

ตัดจบก่อนละกัน

สำหรับตอนนี้เราได้พูดถึงปัญหาที่จะเกิดขึ้นเมื่อใช้งาน Database พร้อมกันไม่ว่าเป็น Lost update , Dirty read, Non repeatable read และเราได้แสดงวิธีการแก้ปัญหาโดยการใช้ Lock ในการ Lock ข้อมูลซึ่งต้อง Implement เอง แต่จริงๆแล้วตัว Database มี Feature ที่จัดการกับปัญหาเหล่านี้เอาไว้แล้ว (อ้าว แล้วจะมีตอนนี้เพื่ออะไรวะ) ดังนั้นในตอนหน้าเรามาดูวิธีการใช้ Feature ของ Database ในการแก้ปัญหากัน

Reference

https://onlinelibrary.wiley.com/doi/abs/10.1002/(SICI)1097-024X(199801)28:1%3C77::AID-SPE148%3E3.0.CO;2-R

เพลงประกอบการเขียน Blog

เพลง Nice to Miss You ของน้องๆวง Wishdom

Vault Plugin Part 3 - Read Plugin Code

มาเขียน Vault Plugin กันเถอะ : ตอนที่ 3 ทำความเข้าใจ Code

จากตอนที่แล้วเราได้สร้าง Mock plugin และนำมันขึ้นไปบน server เรียบร้อยแล้ว ตอนนี้เรามาทำความเข้าใจ Code ดีกว่า เพราะเมื่อเข้าใจแล้วเราก็สามารถทำตัว Plugin ของเราขึ้นมาเองได้ หรือ ไปเอา Plugin คนอื่นมา Customize ให้ได้ตรงตามความต้องการของเรา

Default code ที่ต้องมี

1
2
3
4
5
git clone https://github.com/hashicorp/vault-guides.git
cd vault-guides

# Source code มันมีการ Update หลังจากผมเขียน Blog เลยต้องย้ายมา commit
git checkout e0eb4285d8066770bc1f50056c27e2c6e4a989e1

Code ส่วนที่ต้องมีคือ Code ในไฟล์ secrets/mock/cmd/mock/main.go ซึ่งในไฟล์นี้ไม่ทำอะไรมากมันเหมือนเป็น interface ของ plugin เวลาตัว vault มาเรียกใช้งานจะทำการมาเรียกที่ไฟล์นี้ ดังนั้นถ้าเราจะ Custom อะไรเราก็เพียงแค่ import ตัว soruce code ของเราที่มี Function Factory เหมือนกับ mock ในตัวอย่าง

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
package main

import (
"os"
"github.com/hashicorp/go-hclog"
// ตัวนี้ถูก import มา
mock "github.com/hashicorp/vault-guides/secrets/mock"
"github.com/hashicorp/vault/api"
"github.com/hashicorp/vault/sdk/plugin"
)

func main() {
apiClientMeta := &api.PluginAPIClientMeta{}
flags := apiClientMeta.FlagSet()
flags.Parse(os.Args[1:])

tlsConfig := apiClientMeta.GetTLSConfig()
tlsProviderFunc := api.VaultPluginTLSProvider(tlsConfig)

err := plugin.Serve(&plugin.ServeOpts{
// ตรงนี้แหละ จะไปเรียก package mock ให้ทำงาน
BackendFactoryFunc: mock.Factory,
TLSProviderFunc: tlsProviderFunc,
})
if err != nil {
logger := hclog.New(&hclog.LoggerOptions{})

logger.Error("plugin shutting down", "error", err)
os.Exit(1)
}
}

ตัว Code จริงๆที่ทำงาน

ตัว Code จริงๆที่ทำงานทั้งหมดจะอยู่ที่ secrets/mock/backend.go โดยจะขออธิบายเป็นส่วนๆนะครับ

ส่วน Factory

ส่วนของ Factory นั้นไม่มีอะไรมากเป็นการ Config ว่า Plugin โดยที่สำคัญสำหรับคือส่วนที่เป็น Path ครับ โดยจะประกาศใน Factory ก็ได้หรือจะทำเป็น Method เหมือน code ตัวอย่างก็ได้ครับ

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// Factory configures and returns Mock backends
func Factory(ctx context.Context, conf *logical.BackendConfig) (logical.Backend, error) {
b := &backend{
store: make(map[string][]byte),
}

b.Backend = &framework.Backend{
Help: strings.TrimSpace(mockHelp),
BackendType: logical.TypeLogical,
}

// ตรงนี้เป็นส่วน Register path ว่า plugin ของเราจะมี path อะไรบ้าง
// แล้วแต่ล่ะ path จะให้ทำอะไรได้บ้าง Create Read Update Delete (CRUD)
b.Backend.Paths = append(b.Backend.Paths, b.paths()...)

if conf == nil {
return nil, fmt.Errorf("configuration passed into backend is nil")
}

b.Backend.Setup(ctx, conf)

return b, nil
}

ส่วน Path

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
func (b *backend) paths() []*framework.Path {
// ตรงนี้มัน Return เป็น Array
return []*framework.Path{
{
// อันนี้เป็นการบอกว่า path ของเราหน้าตาเป็นยังไง ประกาศแบบนี้คือ path ของเราจะเป็น /
// อะไรที่ตามมาจากนี้จะถูกส่งเข้าตัวแปร path
// เช่น จากตอนที่แล้วเรายิงมาที่ /test
// path จะมีค่าเป็น test
Pattern: framework.MatchAllRegex("path"),

// แต่ถ้าประกาศแบบนี้จะบอกว่า path นี้จะ match กับ /bell เวลายิงจะต้องยิงมาเป็น
// /bell/test
// แทน
//Pattern: "bell/" + framework.MatchAllRegex("path"),

// อันนี้เป็นการบอกว่า path นี้รับตัวแปรอะไรบ้าง
Fields: map[string]*framework.FieldSchema{
"path": {
Type: framework.TypeString,
Description: "Specifies the path of the secret.",
},
},

// ตรงนี้เป็นส่วนบอกว่า Path ของเรารับ Operation อะไรบ้างโดยจากตัวอย่าง
// เขารับ 4 Operation เลย
Operations: map[logical.Operation]framework.OperationHandler{
logical.ReadOperation: &framework.PathOperation{
// ตรงนี้บอกว่าจะเอา function อะไรมารับ โดยตัวนี้รับที่ handleRead
// ในของ Operation อื่นๆก็เช่นกัน
Callback: b.handleRead,
Summary: "Retrieve the secret from the map.",
},
logical.UpdateOperation: &framework.PathOperation{
Callback: b.handleWrite,
Summary: "Store a secret at the specified location.",
},
logical.CreateOperation: &framework.PathOperation{
Callback: b.handleWrite,
},
logical.DeleteOperation: &framework.PathOperation{
Callback: b.handleDelete,
Summary: "Deletes the secret at the specified location.",
},
},

// ตรงนี้จะเป็นการ fucntion ไว้ใช้ตรวจสอบว่าสิ่งที่ client ส่งมามีอยู่
// บน server แล้วรึยัง
ExistenceCheck: b.handleExistenceCheck,
},
}
}

ส่วน Operation

ขอพูดถึง handleWrite เลยละกันเพราะ code ส่วนนี้มีทั้งดึงค่าจาก body และ path

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
func (b *backend) handleWrite(ctx context.Context, req *logical.Request, data *framework.FieldData) (*logical.Response, error) {

if req.ClientToken == "" {
return nil, fmt.Errorf("client token empty")
}

// Check to make sure that kv pairs provided
if len(req.Data) == 0 {
return nil, fmt.Errorf("data must be provided to store in secret")
}

// ส่วนนี้คือดึง data จาก path
path := data.Get("path").(string)

// JSON encode the data
// ส่วนนี้คือดึง Body จาก client ออกมา
buf, err := json.Marshal(req.Data)
if err != nil {
return nil, errwrap.Wrapf("json encoding failed: {{err}}", err)
}

// Store kv pairs in map at specified path
b.store[req.ClientToken+"/"+path] = buf

return nil, nil
}

จบละ

สำหรับตอนนี้เป็นการอธิบาย Code ของ Mock Plugin โดยจริงๆแล้วไม่มีอะไรมากเลย แต่ผมอยากเขียนเผื่อคนที่อยากทำ Custom plugin บ้างจะได้ไม่ต้องเสียเวลาทดลองเอง ซึ่งตอนนี้คงเป็นตอนสุดท้ายของ Vault Custom Plugin แล้ว ส่วนตอนหน้าจะเป็นอะไรรอดูกันต่อไปครับ

เพลงประกอบการเขียน Blog

วิธีชนะมิตรและจูงใจคน - How to Win Friends and Influence People

วิธีชนะมิตรและจูงใจคน - How to Win Friends and Influence People

วิธีชนะมิตรและจูงใจคน - How to Win Friends and Influence People

สำหรับหนังสือเล่มนี้ผมไปเจอจากใน Internet ว่าเป็นหนังสือที่คนควรอ่านให้ได้ก็เลยลองหาซื้อดู ปรากฏว่าหมดจ้า ไม่ว่าจะร้านหนังสือไหนจะเหลือก็แต่ในห้องสมุดสถาบันที่ผมเคยอยู่ (ซึ่งผมเรียนจบแล้วใช้ไม่ได้แล้ว) กับหนังสือมือสองซึ่งก็น่าลองแต่เขาไม่รับรองคุณภาพหนังสือซึ่งน่ากลัวว่าจะได้มาแบบหน้าขาดๆ ก็เลยไม่ได้ซื้อ จนเมื่อปีที่แล้วเขามี Re print หนังสือเล่มนี้ ก็เลยไปป่าวประกาศในหน้า Facebook ว่าหนังสือเล่มนี้น่าอ่านเดี๋ยวปีใหม่จะซื้อมาอ่าน ซึ่งปีใหม่ก็ได้หนังสือเล่มนี้มาจริงๆจากการได้เป็นของขวัญ โอเคเราเล่าที่มาของการได้หนังสือเล่มนี้มาเยอะแล้ว (ไม่ได้เกี่ยวกับเนื้อหาในหนังสือ)

การทำยังไงให้คนที่อยากจะสื่อสารสบายใจและประทับใจ

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

เป็นเรื่องที่ควรศึกษา

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

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

ความอ่อนแอของจิตใจมนุษย์

การอ่านหนังสือเล่มนี้นั้นได้บอกวิธีหลายๆอย่างในการทำให้มนุษย์รู้สึกดี รู้สึกสบายใจ รู้สึกมีคุณค่า โดยข้อแรกๆที่คุณ Dale Carnegie เขียนไว้เลยคือ ให้มันมาจาก ใจจริง ตอนแรกก็ไม่เข้าใจว่าทำไมคุณ Dale Carnegie ถึงเขียนไว้อย่างนั้น แต่พออ่านหนังสือเล่มนี้เกือบจบ (ณ ตอนที่เขียน บทสุดท้ายพูดถึงเรื่องสามี ภรรยา เลยยังไม่ได้อ่าน) ก็เลยเข้าใจว่า ทั้งหมดมันคือการเล่นกับจิตใจของมนุษย์ แค่คุณชมหรือพูดอะไรนิดหน่อย คนที่คุณคุยด้วยอาจเปลี่ยนการตอบโต้ชนิดแบบหน้ามือหลังเท้า ตัวอย่างที่แบบ เอาจริงดิ เรื่องนึงคือ การเจรจารวมธุรกิจที่ยากเย็นแสนเข็ญแบบตกลงกันไม่ได้สักที กลับจบแบบง่ายๆโดยฝ่ายหนึ่งบอกว่าชื่อบริษัทที่จะรวมกันชื่อของคุณ แค่นั้นการตกลงง่ายดายขึ้นมาในทันที หรือ พนักงานคนหนึ่งทำงานควงกะประมาณ 12 - 13 ชั่วโมงต่อวัน เขาเรียกร้องให้บริษัทจ้างคนมาทำงานเพิ่มเพื่อช่วยเขา แต่บริษัทใช้วิธีการสร้างห้องให้พนักงานคนนั้นให้ชื่อตำแหน่งเท่ห์ๆ แปะหน้าห้องว่าเป็นห้องของพนักงานคนนั้นแปะป้ายตำแหน่งใหญ่โตให้ หลังจากนั้นพนักงานคนนั้นไม่บ่นอะไรอีกเลย หรือตัวอย่างเกี่ยวกับทหารก็คือ นโปเลียนสร้างยศให้ทหารที่ออกรบให้มียศต่างๆ มีเหรียญกล้าหาญให้ ทำให้พวกทหารพวกนั้นจงรักภักดีอยากไปรบอีก (ดูไปมันก็คล้ายๆกับบางประเทศที่มียศนายพลเยอะซะเหลือเกิน)

จริงๆมันก็เหมือนการเล่นเกมส์นั่นแหละครับ แต่มันไม่ใช่เกมส์ที่เป็นเลข 0 กับ 1 แต่เป็นเกมส์ของมนุษย์ เล่นกับอารมณ์คำพูด สำหรับผมถ้าไม่ได้อ่านหนังสือเล่มนี้การมีคนชม หรือคนพูดดีด้วย ด้วยวิธีต่างๆที่กล่าวมาอาจจะทำให้ผมไม่คิดอะไร แต่พออ่านแล้วรู้แล้วก็จะกลายเป็นว่าคนที่พูดด้วยต้องการอะไร เขากำลังจะเล่นเกมส์กับจิตใจของผม เราควรจะตอบยังไงให้มันดูดีและเล่นเกมส์กลับไปหาเขาด้วยเพราะเราไม่ได้ต้องการอย่างที่เขาต้องการ สุดท้ายจากจะเป็นการสื่อสารให้ได้ผลดีมันจะกลายเป็นการทำสงครามกัน ดังนั้นคุณ Dale Carnegie จึงแนะนำว่า การจะทำอะไรแบบนี้ขอมันมาจาก ใจจริง แต่คำถามคือ เราจะรู้ได้ไงว่ามันมาจาก ใจจริง

สรุป

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

เพลงประกอบการเขียน Blog

Vault Plugin Part 2 - Create Plugin

มาเขียน Vault Plugin กันเถอะ : ตอนที่ 2 สร้าง Plugin

ในตอนที่แล้วเราสามารถ Start Vault server ขึ้นมาใช้งานได้แล้ว ตอนนี้เรามาลองสร้าง Vault plugin ขึ้นมาใช้งาน ซึ่งจริงๆมันมีตัวอย่างที่ Web ของ Vault อยู่แล้วตาม Link นี้ ซึ่งก็บอกละเอียดดีแต่มันขาดส่วนที่เกี่ยวกับการอธิบาย Code แล้วจริงๆมันสร้างสั่งผ่าน Rest api ได้ด้วย ซึ่งน่าใช้กว่า cmd เพราะสามารถจัดข้อมูลก่อนส่งได้ ถ้าเป็น cmd ต้องเป็นบรรทัดเดียว (จริงๆทำหลายบรรทัดก็ได้นะ แต่ไม่ค่อยชอบ)

Compile plugin กันก่อน

ขั้นตอนแรกไป Clone ตัว Plugin มาก่อนโดยใช้คำสั่ง

1
2
3
4
5
git clone https://github.com/hashicorp/vault-guides.git
cd vault-guides

# Source code มันมีการ Update หลังจากผมเขียน Blog เลยต้องย้ายมา commit
git checkout e0eb4285d8066770bc1f50056c27e2c6e4a989e1

จากนั้นย้ายเข้าไปใน Directory ของ plugin ตัวอย่าง

1
cd vault-guides/secrets/mock

ตรงจุดนี้คือการเอา Docker ของ go มา compile code ให้

1
2
3
4
5
6
7
8
9
10
11
# ทำการสร้าง docker ขึ้นมา โดยสั่งคำสั่งนี้แล้วมันเข้าไปอยู่ในเครื่อง docker ที่เราสร้างสำหรับทำการ compile
docker run -ti --rm -v "$PWD:/go/src/plugin" golang:1.14-buster bash

# ย้ายไป Directory ที่ Source เราอยู่
cd /go/src/plugin

# ทำการสั่ง Build ตัว Plugin
CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o vault/plugins/mock cmd/mock/main.go

# ทำการออกจาก Docker
exit

จากนั้นตรวจสอบ directory ของเราจะได้ดังด้านล่าง

1
2
3
4
5
6
7
8
9
10
11
12
.
├── backend.go
├── cmd
│   └── mock
│   └── main.go
├── go.mod
├── go.sum
├── Makefile
├── README.md
└── vault
└── plugins
└── mock

โดยผลลัพธ์จากการ compile จะอยู่ใน ./vault/plugins/mock ให้ copy ไฟล์นี้ไว้นะครับ

Register Plugin เข้าไปใน Vault server

ในการ Register plugin ของ vault นั้นเราจะต้องเอาไฟล์ Plugin ไปวางไว้ใน Directory plugin บน Vault server ซึ่งจากขั้นตอนที่แล้วที่ให้ copy ไฟล์ ./vault/plugins/mock แล้วไปวางไว้ที่ Directory ของ Vault server ในตอนที่แล้ว ซึ่ง path ที่จะให้ไปวางก็คือ plugin/mock

1
2
3
4
.
├── data
├── plugin
│   └── mock

แต่การวางไฟล์ไว้บนเครื่องยังไม่น่าเชื่อถือว่าคุณคือคนทำ plugin นั้นจริงๆ แล้ว plugin นั้นใช่ตัวเดียวกับวางบน server รึเปล่า ดังนั้นเขาเลยใช้ hash เช็คไฟล์ด้วยซะเลย ดังนั้นในการเราต้องค่า hash ของ plugin นั้นด้วย โดยใช้คำสั่ง

1
2
3
4
5
openssl dgst -sha256 mock

# ผลลัพธ์จะได้แบบนี้ แต่ของคุณอาจจะไม่เหมือนของผม เพราะการ compile อาจจะได้ค่าไม่เท่ากันก็ได้
# SHA256(mock)= c0798363e1dd0ec1c1a8cfe0865654cd7d6b6e0f83401d672e43b4dab1202eb8
# ให้ copy c0798363e1dd0ec1c1a8cfe0865654cd7d6b6e0f83401d672e43b4dab1202eb8 เก็บไว้

จากนั้นเราจะทำการ Register Plugin โดยใช้ Rest api ที่ Vault มีให้ โดยรายละเอียด Api สามารถดูได้ที่ Link นี้ โดยผมจะใช้ Postman ในการยิง Http Request ( ท่านสามารถ Download Collection และ Environment ของ Postman ได้ที่นี่)

ยิง Register Plugin

ตัว Body ที่ยิง

1
2
3
4
{
"sha256": "c0798363e1dd0ec1c1a8cfe0865654cd7d6b6e0f83401d672e43b4dab1202eb8",
"command": "mock"
}

ตรวจสอบว่า Register สำเร็จไหม

โดยถ้าสำเร็จจะต้องมี plugin ชื่อ mock โผล่ในส่วนของ Secret engine ครับ

นำ Plugin มาใช้งาน

ในขั้นตอนเราแค่ทำการ Register plugin เข้าไปในระบบ ให้ระบบทราบว่ามี Plugin นี้อยู่ในระบบนะ แต่เรายังไม่ได้เอา plugin มาใช้งาน โดยถ้าจะเอา plugin ไปใช้เราจะต้องเอามันไป Mount ที่ path โดย 1 plugin สามารถ mount ได้หลาย path โดยจะถือว่าเป็นคนละตัวกันเลย โดยรายละเอียดเกี่ยวกับ api ที่ใช้ Mount plugin ไปที่ path สามารถอ่านได้ที่ Link

Mount plugin to path

ทำการ Enable plugin โดยทำตามภาพ

โดยหา Register สำเร็จเมื่อเข้ามาดูหน้า Web จะเห็นว่ามี Path mock/ โผล่มาที่หน้าจอแล้วดังภาพ

ทดสอบ Mock plugin

Mock plugin ที่เราสร้างขึ้นมานั้นมีหน้าที่เก็บค่าที่ส่งเข้าแล้วเก็บไว้ที่ Path ที่ต้องการ โดยตัวอย่างเราจะเก็บข้อมูลที่ path : test โดยเก็บข้อมูล

1
2
3
{
"message" : "Secret value : qtaaNdjaddzhdrjit"
}

จากนั้นลอง Get ข้อมูลก็จะได้ข้อมูล

1
2
3
4
5
6
7
8
9
10
11
12
{
"request_id": "28e109fc-6657-647b-97e8-bf542232bd72",
"lease_id": "",
"renewable": false,
"lease_duration": 0,
"data": {
"message": "Secret value : qtaaNdjaddzhdrjit"
},
"wrap_info": null,
"warnings": null,
"auth": null
}

จบก่อนเขียนมาเยอะละ

สำหรับตอนนี้เราได้เรียนรู้วิธีการสร้าง Plugin (จริงๆเอา plugin ตัวอย่างมาใช้) แล้วก็วิธี Register plugin เข้าไปในระบบ แล้วก็เอา Plugin มา Mount ที่ Path เพื่อใช้งาน ในส่วนของตอนถัดไปเรามาดูเรื่อง Code ของ Plugin ตัวอย่างว่ามันทำงานยังไง แล้วลองเปลี่ยน Plugin เล่นกันดู

เพลงประกอบการเขียน Blog