wiennat

The Wealth Ladder

Thu, 30 Oct 2025 00:00:00 GMT

แต่ส่วนตัวคิดว่าพอเค้าแบ่งแต่ละขั้นเป็นตัวเลขมันแล้วทำให้จำลำดับจำยาก เลยขอมาสรุป

เรื่องของตัวเลขใน It's over 9000!

Fri, 11 Aug 2023 01:53:52 GMT

หลายๆ คนคงรู้ว่ามีม It’s over xxxx! นั้นมีที่มาจากฉากหนึ่งในดราก้อนบอล เนื้อเรื่องคือช่วงที่เบจิต้ามาบุกโลกครั้งแรกๆ แล้วเครื่องวัดพลังบอกว่าพลังของโกคูนั้นมีพลังเพิ่มขึ้นมากกว่า 9000 จุดจนทำให้เบจิต้าตกใจ

ถ้าเข้าไปอ่านในวิกิพีเดียของมีมนี้ ก็จะรู้ว่า จริงๆ แล้วในบทจะต้องพูดว่า “It’s over 8000!” ตามแบบในภาคภาษาญี่ปุ่น 「8000以上だ…!」ซึ่งภาษาอื่นๆ รวมทั้งภาษาไทยก็แปลตามนี้ทั้งสิ้น

แต่ว่าทีมที่แปลบทพากย์นั้นบอกว่าตัวเลข 9000 นั้นเข้ากับการขยับปากของเบจิต้ามากกว่าก็เลยเปลี่ยนบทไปเป็น “It’s over 9000!” แต่ก็มีคนให้ข้อสังเกตว่าทีมแปลนี้มักแปลผิดอยู่บ่อยๆ อยู่แล้ว ดังนั้นรอบนี้ก็น่าจะแปลผิดเช่นกัน

ทำไมเบจิต้าถึงพูดว่า It’s over 8000 ตั้งแต่แรก

หลายๆ บทความที่หามาก็มักจะจบการอธิบายว่าเบจิต้าพูด “It’s over 9000!” เพราะมันเข้ากับภาพได้ดีกว่า “It’s over 8000” แค่นั้น แต่ที่น่าสนใจไม่แพ้กันก็คือ ในวิกิพีเดียอธิบายเพิ่มว่าทำไมเบจิต้าถึงระบุถึงตัวเลขนี้เข้าไปด้วย

เหตุผลก็คือตัวเลข 8000 นั้นเป็นตัวเลขแบบ indefinite hyperbolic ของญี่ปุ่น ตัวเลขแบบนี้ก็คือพวกตัวเลขหรือจำนวนที่มีความหมายว่ามีค่าเยอะมากๆ โดยไม่ได้หมายถึงจำนวนที่ระบุแต่อย่างใด

ตัวอย่างของจำนวนประเภทนี้ในภาษาไทยก็เช่นคำว่า ร้อยแปดหรือร้อยแปดพันเก้า ก็ไม่ได้จำเป็นจะต้องหมายถึง 108 เป๊ะๆ แต่มีความหมายโดยนัยว่ามากมายอยู่ ในภาษาอังกฤษก็จะเป็นคำจำพวก -illion เช่น zillion, gajillion เป็นตัน ส่วนของอาหรับก็จะเป็นตัวเลข 1001 อย่างชื่อนิทาน พันหนึ่งราตรี ก็น่าจะมีความหมายโดยนัยว่าเป็นเวลานานมากๆ นั่นแหละ

ไม่รู้ว่าเป็นความตั้งใจของผู้ที่แต่งเรื่องนี้ตั้งแต่แรกรึเปล่าที่ให้เบจิต้าพูดว่า “It’s over 8000!” ก็จะได้เพิ่มความรู้สึกให้คนอ่านมังงะคิดว่าพลังของโกคูเยอะมากๆ เข้าไปอีกนั่นเอง

The Making of Dune II

Thu, 05 Jan 2023 16:00:00 GMT

วันก่อนได้ไปอ่านบทความเกี่ยวกับการสร้างเกม Dune II ที่อยู่บนเว็บไซต์ Read Only Memory มา แล้วมีอะไรหลายๆ อย่างน่าสนใจดี

เกม Dune II เป็นเกม RTS เกมแรกๆ ที่มีการสร้างมาเลย โดยอ้างอิงเนื้อเรื่องมาจากนิยายคลาสสิคที่ชื่อเดียวกัน โดยอ้างอิงเนื้อเรื่องมาจากภาพยนตร์ที่ออกฉายในปี 1984 ที่กำกับโดย David Lynch
เนื้อเรื่องก็เข้าใจง่ายมาก มีตระกูลใหญ่สามตระกูลแย่งชิงความเป็นใหญ่กันในดาว Arrakis เราจะต้องเลือกเป็นผู้นำของหนึ่งในสามตระกูลนั้นแล้วก็เก็บแร่ สร้างฐาน กองทัพ เพื่อขยายดินแดนไปเรื่อยๆ จนครอบครองทั้งดาว
ในช่วงเวลาไล่เลี่ยกันกับที่ Dune II วางตลาด ก็มีเกม Dune ภาคหนึ่งวางตลาดอยู่เช่นกัน แต่ทั้งสองก็ไม่ได้มีความเกี่ยวเนื่องกัน ไม่ได้เป็นภาคต่อของกันและกันแต่อย่างใด
ถึงแม้ว่าจะเป็นเกมต้นแบบของเกมประเภท RTS แต่ Dune II ก็ได้แรงบันดาลใจและไอเดียมาจากเกมอื่นๆ มากมายอย่าง Herzog Zwei (Technosoft, 1986, Sega Mega Drive) และ Military Madness (1990, Hudsonsoft) รวมไปถึงการใช้เมาส์ที่ได้แรงบันดาลใจจาก Populous (1989, Bullfrog)
คอมพิวเตอร์จะโกงเล็กน้อยตรงที่ได้เงินต่อรถขนแร่เยอะกว่าผู้เล่น แล้วก็รู้ว่ายูนิตของผู้เล่นอยู่ไหน
คนออกแบบด่านจะออกแบบไว้ล่วงหน้าแล้วว่าอยากให้ฐานทัพของฝั่งคอมพิวเตอร์เป็นยังไง เสร็จแล้วก็ค่อยๆ ย้อนหลังไปว่าตอนเริ่มเกมในแต่ละด่านควรจะต้องเป็นยังไง
Westwood ไม่อยากทำภาคต่อของ Dune II เพราะไม่อยากจ่ายค่าลิขสิทธิ เลยสร้าง Command & Conquer ขึ้นมาแทน

The biggest single thing I should have added to it was the ability to drag-select units to allow a player to issue one order simultaneously to multiple units.

Joe Bostic ที่เป็นหัวหน้าโปรแกรมเมอร์บอกว่า ฟีเจอร์ที่อยากใส่ใน Dune II มากที่สุดคือการเลือกยูนิตจำนวนมากด้วยการ Drag ซึ่งแค่นั้นก็ทำให้ C&C มีพัฒนาการที่ก้าวกระโดดไปจาก Dune II มากแล้ว
โค้ดต่างๆ ที่ถูกใช้ใน Dune II ก็เอามาสร้าง C&C, Red Alert, Tiberian Sun ไปตามลำดับ

ทำไมคนอเมริกันเรียกฟุตบอลว่า Soccer?

Thu, 22 Dec 2022 04:00:00 GMT

หลายเดือนก่อนบอลโลกจะเริ่มต้นขึ้น มีเพื่อนถามว่า ทำไมอเมริกันฟุตบอลถึงถูกเรียกว่าฟุตบอลทั้งๆ ที่มันเตะอยู่แค่แป๊บเดียว พอลองไปหาๆ ดูก็เลยทำให้รู้ว่าทำไมคนอังกฤษเรียกว่า Football แต่คนอเมริกันเรียกฟุตบอลว่า Soccer และรู้มั้ยว่าจริงๆ แล้วอังกฤษเองก็เรียกกีฬาประเภทนี้ว่า Soccer มาก่อนเช่นกัน

สรุปแบบเข้าใจง่ายๆ ก็คือ

กีฬาที่ใช้เท้าเตะลูกบอลมีมานานมากแล้ว แล้วก็มีหลายประเภทด้วย ทั้งหมดรวมเรียกว่าฟุตบอล อย่างรักบี้ก็จัดเป็นหนึ่งในกีฬาฟุตบอลเช่นกัน
กีฬาที่ทุกวันนี้เรียกว่าฟุตบอลนั้น เริ่มมาจากการที่อังกฤษตั้งสมาคมฟุตบอลหรือ Football Association (FA ที่เรารู้จักกันดีนั่นแหละ) ที่คอยกำหนดกฏกติกาสำหรับการเล่นฟุตบอลขึ้นมา เจ้ากีฬาประเภทนี้ก็ได้รีบการเรียกชื่อว่าเป็น Association Football เพื่อระบุให้ชัดจากกีฬาฟุตบอลประเภทอื่นๆ
ทีนี้ก็มีคนที่คิดคำเรียกนักกีฬาขึ้นมาเพราะไม่งั้นชื่อมันจะยาว อย่างนักกีฬารักบี้ก็เรียกว่า Rugger และนักกีฬา Association Football ก็เรียกว่า Assoccer แล้วก็เลยโดนกร่อนเสียงให้เหลือแค่คำว่า Soccer ในเวลาต่อมา
เพียงแต่ว่าชื่อนี้มันก็เป็นแค่ชื่อเล่น ไม่ได้รับความนิยมอะไรมากนัก พอตอนหลังที่ Association Football ได้รับความนิยมมากเข้า พอพูดถึงฟุตบอล คนก็จะนึกถึง Association Football ก่อน
ทีนี้ฝั่งอเมริกาที่มีการเล่นกีฬา gridiron football กันอยู่แล้วก็เลยชินกับการเรียกกีฬา gridiron football ว่าฟุตบอลอยู่แล้ว
ดังนั้นนักกีฬา Association Football ในอเมริกาก็เลยเรียกกีฬานี้ว่า Soccer เพื่อไม่ให้สับสนแล้วก็ใช้กันต่อมาเรื่อยๆ

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

ref - https://www.britannica.com/story/why-do-some-people-call-football-soccer

Pingora พร็อกซีตัวใหม่ของ Cloudflare ที่มาแทน nginx

Wed, 21 Sep 2022 02:00:00 GMT

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

nginx ในระบบของ Cloudflare

ก่อนเราจะเริ่มไปพูดถึงว่า nginx มีปัญหาอย่างไร เราลองมาดูกันก่อนว่า Cloudflare ใช้งาน nginx อย่างไรบ้าง

ปกติแล้ว Cloudflare จะทำหน้าที่เป็นตัวกลางที่อยู่ระหว่างไคลเอนต์ (เครื่องผู้ใช้, บราวเซอร์, แอปหรืออุปกรณ์ต่างๆ) ที่เรียกใช้งานเซิฟเวอร์ (API Server) โดย Cloudflare นั้นเลือกใช้ nginx เพื่อใช้เป็นพร็อกซี (Proxy) ที่จะส่งต่อการคุยกันระหว่างเครื่องผู้ใช้และเซิฟเวอร์ เมื่อบวกกับการที่ Cloudflare มีเครื่อง edge server ที่อยู่ใกล้กับไคลเอนต์มากๆ ทำให้การใช้งานโดยทั่วไปมีประสิทธิภาพสูงกว่าการเรียกเซิฟเวอร์แบบตรงๆ

หนึ่งในวิธีที่ Cloudflare ใช้เพื่อช่วยเพิ่มประสิทธิภาพก็คือ Connection reuse ซึ่งแทนที่จะต้องสร้าง connection จากพร็อกซีไปยังเครื่องเซิฟเวอร์ทุกครั้งที่มี request เข้ามา ก็ให้ nginx เก็บ connection เก่าๆ เอาไว้ใน connection pool หากมี request ใหม่ที่ต้องการใช้งานเซิฟเวอร์เดิมก็แค่เอา connection ใน pool ออกมาใช้ เท่านี้ก็ช่วยลดเวลาและหน่วยความจำที่ต้องใช้สร้าง connection ได้แล้ว

ปัญหาของ nginx ใน Cloudflare

ช่วงก่อนหน้านี้ Cloudflare นั้นก็มีการพูดถึงปัญหาในการใช้งาน nginx มาอยู่บ้างคือ

ข้อจำกัดของ architecture ที่ nginx ใช้นั้นมีผลต่อ performance
- nginx ใช้ worker ในระดับ process และหนึ่ง request จะถูก handle ด้วย process เดียวแบบไม่มี work stealing แปลว่าถ้ามี request ที่ใช้งาน CPU หนักๆ หรือใช้ blocked I/O ก็จะทำให้ request อื่นๆ ช้าตามไปด้วย
- nginx ยังมีปัญหาว่าจะ schedule งาน worker แบบไม่เท่าเทียมกัน ทำให้ปัญหาข้างต้นมีผลกว่าเดิม
- ไม่มีการแชร์ connection pool ข้าม worker process - ถ้า process ที่รับ request จะเป็นเครื่องเดียวกันแต่เป็นคนละ process ก็ต้องสร้าง connection ใหม่อยู่ดี
เพิ่มฟีเจอร์อื่นๆ ได้ยาก - ถึง nginx จะมีให้เขียนโมดูลเพิ่มเติมได้ แต่ถ้าไม่เข้ากับสิ่งที่ nginx ออกแบบไว้ก็อาจจะทำได้ยาก
อีกสิ่งที่พูดถึงแต่ละไว้เป็นตัวเล็กๆ คือเดฟของ nginx ไม่ค่อยแอคทีฟในคอมมูนิตี้แต่ไปงุบงิบทำกันเอง

แนวทางการแก้ปัญหาของ Cloudflare

Cloudflare อธิบายว่ามีสามทางเลือกเพื่อแก้ปัญหานี้

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

ที่น่าสนใจคือก่อน Cloudflare จะตัดสินใจแบบนี้ก็ได้ประเมินทางเลือกทุกๆ ไตรมาสมาซักระยะแล้ว (ในบทความใช้ว่า for a few years) ซึ่งผลก็คือใช้ nginx ต่อจนสุดท้ายก็เห็นว่าลงทุนทำใหม่เลยคุ้มค่ากว่าก็ค่อยตัดสินใจเริ่มทำของตัวเอง

Design Decision ใน Pingora project

Cloudflare เลือกใช้ Rust เพราะอยากได้ Performance แบบ C แต่มีความ memory-safe อยู่ อีกเหตุผลน่าจะเพราะว่ามีการใช้ Rust ในหลายๆ โปรดักส์อยู่แล้ว

เลือกจะอิมพลีเมนต์ไลบรารี HTTP ขึ้นมาใหม่เพื่อตอบสนองความใช้งานตัวเอง เพราะไลบรารีที่เป็น 3rd-party อาจจะเลือกทำตามมาตรฐานอย่างเคร่งครัดและปฏิเสธ request ที่ไม่ตรงตามมาตรฐาน แต่ลูกค้าของ Cloudflare นั้นอาจจะใช้ request ที่ไม่ตรงมาตรฐานที่ว่านั้นก็ได้ ทำให้อยู่ในสภาพที่ต้องเลือกระหว่าง “ความถูกต้องหรือความถูกใจ” ซึ่ง Cloudflare เลือกความถูกใจ
ใช้ Multi-threading แทน Multi-processing เพื่อแชร์ข้อมูลกันระหว่าง worker โดยเฉพาะ connection pool และ อนุญาตให้มี work stealing เพื่อลดปัญหาที่งานกระจุกอยู่ที่ worker เดียวโดยที่ worker อื่นไม่มีงานทำ
ทำเป็น extensible platform ที่ให้กลุ่มอื่นมาเพิ่มฟีเจอร์ได้ง่ายๆ

ผลหลังจากเอา Pingora มาใช้

หลังจากใช้งานใน production มาระยะหนึ่ง Cloudflare ก็สรุปออกมาว่า Pingora นั้นเร็วกว่า nginx จริงๆ
ที่เป็นแบบนี้ก็เพราะมีการแชร์ข้อมูลกันระหว่าง Worker มากขึ้น ทำให้จำนวน connection ที่สร้างต่อวินาทีนั้นเหลือแค่ 1/3 ของระบบเก่า อัตราส่วนของการใช้ connection ซ้ำในระบบของลูกค้ารายหนึ่งเพิ่มขึ้นจาก 87 1% -> 99 2% หรือถ้าคิดเป็นจำนวน connection ที่สร้างขึ้นใหม่ก็จะเหลือแค่ 1/160 ของของเดิม
แล้วพอเป็นของตัวเอง จะทำอะไรก็ง่ายไม่ต้องเสียเวลาคุยกันข้ามองค์กร ทำให้เข็นฟีเจอร์ใหม่ๆ ออกมาได้ง่ายขึ้น
ประหยัดขึ้น เพราะใช้ซีพียูน้อยลง 70% ใช้หน่วยความจำน้อยลง 67% เมื่อเทียบกับระบบเดิมและโหลดเท่าเดิม เหตุผลเพราะนอกจาก Rust ทำงานได้มีประสิทธิภาพกว่า Lua แล้วยังไม่ต้องไปใช้การทำงานที่ต้องข้ามไปข้ามมาระหว่าง C <-> Lua แบบใน nginx และอีกเหตุผลคือ พอมีการใช้ซ้ำ connection มากๆ ก็ประหยัดเวลาการทำ TLS handshaking ที่เปลืองเวลาซีพียู
สิ่งที่เป็น by product คือปลอดภัยขึ้นเพราะส่วนใหญ่ถ้ามีปัญหาก็มักจะไม่ได้เกิดจาก Pingora ทำให้ตรวจพอปัญหาในจุดอื่นๆ ที่ไม่รู้มาก่อนเพิ่มมากขึ้น

สรุป

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

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

สรุปจาก: https://blog.cloudflare.com/how-we-built-pingora-the-proxy-that-connects-cloudflare-to-the-internet/

ปล 1. ยังไม่เปิดซอร์สและคิดว่าน่าจะไม่เปิดด้วย

ปล 2. นั่งอ่านไปก็พบว่าคนเขียนบทความนี่แซะ nginx แทบทุกย่อหน้า

Starbucks Cup Sizes

Tue, 05 Jul 2022 15:00:00 GMT

Starbucks มีชื่อเรียกขนาดแก้วของตัวเองที่ไม่ค่อยเหมือนชาวบ้าน ส่วนตัวปกติก็จะสั่งแก้ว Tall แต่ก็ไม่เคยจำได้ซักทีว่าจริงๆ แล้วเจ้าไซส์ Tall มันขนาดเป๊ะๆ เท่าไหร่

หลักๆ แล้วเครื่องดื่มในร้านจะมีทั้งหมดสี่ขนาดคือ short, tall, grande, venti และมี trenta ที่ไม่เคยเห็นบนเมนู

short (8 oz) → 236 ml
tall (12 oz) → 354 ml
grande (16 oz) → 473 ml
venti (hot) (20 oz) → 591 ml
venti (cold) (24 oz) → 709 ml
trenta (31 oz) → 916 ml อันนี้ไม่เคยเห็นในญี่ปุ่น ไม่รู้ว่าสั่งได้มั้ย

เมนูไหนที่ไม่ได้เขียนว่ามี Short ก็อาจจะขอสั่งขนาดเป็น short ได้

พอจำได้ก็ดูคลิปนี้ต่อ

ref - https://customerservice.starbucks.com/app/answers/detail/a_id/3113/~/what-are-the-sizes-of-starbucks-drinks

Surprisingly Synchronization

Mon, 09 May 2022 15:00:00 GMT

เมื่อบ่ายวันก่อนลองกดวิดีโอของ Veritasium ที่ชื่อ “The Surprising Secret of Synchronization” มาดูเพราะมันขึ้นมาเป็นวิดีโอแนะนำหลังจากวิดีโอที่ดูอยู่จบ

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

หรือสะพาน Broughton ที่ถล่มในช่วงที่ทหารเดินสวนสนามผ่าน

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

ที่น่าประหลาดใจก็คือ บ่ายวันนั้นก็มีข่าวผลการสำรวจที่ตึกของ SM Entertainment สั่นพอดี ผู้เชี่ยวชาญรายงานผลการสำรวจว่าการสั่นเกิดจากการซ้อมเต้นที่มีอย่างหนาแน่น (concentrated) ในชั้น 9 และ 10 ซึ่งก็ตรงกับชั้นที่ SM Entertainment เช่าไว้ทำเป็นห้องซ้อมพอดี

ก็นับว่าเป็นเรื่องประหลาดดีเหมือนกันที่ได้ดูวิดีโออธิบายแล้วก็มาอ่านข่าวนี้ต่อ เลยเข้าใจมากขึ้นว่ามันน่าจะเกิดจากอะไร

โค้ดสำหรับทดสอบ Connection reset by peer

Mon, 25 Apr 2022 02:30:00 GMT

หลายเดือนก่อนเจอปัญหาที่แก้ไม่ตกว่าทำไมอยู่ๆ ก็มี log ที่ API Server ที่เขียนด้วย Kotlin บอกว่าดึงข้อมูลไม่ได้ออกมาเต็มไปหมด พอเช็คในรายละเอียดของ log พบว่าทุกอันชี้ไปที่สาเหตุเดียวกันหมดคือ MonoCoroutine was canceled แต่ก็ไม่ได้มีรายละเอียดอะไรมากไปกว่านั้น

หลังจากหามาอยู่สองเดือนก็เดาว่ามันน่าจะเกิดจากการที่อีกฝั่งตัดการเชื่อมต่อไปโดยไม่บอก (Connection reset by peer) เลยไปตามหาโค้ดที่ใช้ทดสอบมาเป็น Java ประมาณนี้

package net.onedd;

import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.io.PrintWriter;
import java.net.Socket;

public class Application {
    public static void main(String[] args) throws Exception {
        System.out.println("starting");
        Socket s = new Socket("localhost", 5000);
        PrintWriter out = new PrintWriter(s.getOutputStream(), true);
        BufferedReader in = new BufferedReader(new InputStreamReader(s.getInputStream()));
        out.println("GET /echo?m=a HTTP/1.1");
        out.println("");
    }
}

หวยญี่ปุ่น ซื้อแล้วเงินไปไหน

Wed, 30 Mar 2022 15:00:00 GMT

เมื่อสองสามปีก่อนดูรายการขอตามไปบ้าน (家ついていっていいですか？)　แล้วมีการพูดถึงว่ารายได้จากการซื้อลอตเตอรี่ในญี่ปุ่นนั้นจะถูกบริจาคเพื่อไปทำประโยชน์ให้สาธารณะ บวกกับว่าปีก่อนมีประเด็นเรื่องเงินบริจาคของกองสลาก ก็เลยสงสัยขึ้นมาว่า รายได้จากการขายหวยของญี่ปุ่นนั้นถูกจัดสรรปันส่วนยังไง

อ้างอิงจากเว็บไซต์ https://www.takarakuji-official.jp/about/proceeds/top.html ระบุรายละเอียดของรายได้และการใช้จ่ายเงินของสมาคมหวยของญี่ปุ่นไว้ดังนี้

ยอดจัดจำหน่ายทั้งหมดของปีเรวะที่ 2 อยู่ที่ 816 พันล้านเยน (หรือแปดแสนล้านเยน) คิดเป็นเงินไทยก็ประมาณสองแสนล้านบาทนิดๆ
47.0% (383.9 พันล้านเยน ประมาณแสนล้านบาท) - ใช้เพื่อเป็นเงินรางวัล
36.6% (298.2 พันล้านเยน ประมาณเกือบๆ เก้าหมื่นล้านบาท) - มอบให้เมืองต่างๆ เพื่อใช้พัฒนาสาธารณประโยชน์ เช่นป้องกันและแก้ปัญหาผู้สูงอายุ ปัญหาเด็กเกิดน้อย ภัยธรรมชาติ ฯลฯ
15.5% - ค่าสิ่งพิมพ์ ค่าใช้จ่ายเพื่อจัดจำหน่าย

ส่วนของไทย เว็บไซต์ของกองสลากมีระบุไว้เหมือนกันในหน้านี้ https://www.glo.or.th/about/performance/revenue

以上

Imakita Sangyou

Fri, 04 Mar 2022 09:26:00 GMT

คำว่า 今北産業 แปลเป็นไทยแบบสวยๆ ได้ว่า อิมาคิตะอุตสาหการ ฟังดูแล้วอาจจะฟังดูเหมือนชื่อกิจการหรือชื่อบริษัทอะไรซักอย่าง แต่ความจริงแล้วกลับไม่ได้มีความหมายแบบนั้นเลยแม้แต่นิดเดียว

คำว่า 今北産業 เป็นคำสแลงในภาษาญี่ปุ่น ว่ากันว่ามีต้นกำเนิดมาจากบอร์ด 2ch โดยคันจิสี่ตัวนี้ที่อ่านว่า อิมาคิตะซังเกียว มันไปพ้องกับคำว่า

「いま」หรือ「今」อ่านว่า อิมะ แปลว่าตอนนี้
「きた」อ่านว่า คิตะ แปลว่า มาแล้ว และพ้องเสียงกับคำว่า 「北」ที่แปลว่าทิศเหนือ
「３行」อ่านว่า ซังเกียว แปลว่า สามบรรทัด และพ้องกับคำว่า 「産業」ที่แปลว่าอุตสาหกรรม

พอเอาทั้งสามคำมาติดกัน มันก็จะกลายเป็นภาษาปากที่ถ้าเคยเรียนภาษาญี่ปุ่นมา หลายคนก็น่าจะพอเข้าใจได้ว่ามันย่อมาจากเต็มๆ ว่า 「今来た（から）、（状況を）3行（で説明して）」 หรือแปลเป็นภาษาไทยได้ว่า ”เพิ่งมาอะ ขอสรุปสั้นๆ สามบรรทัด” นั่นเอง ให้ลองนึกถึงว่าเราล็อกอินเข้ามาในห้องแชทหรือในเกม แล้วเพื่อนกำลังคุยอะไรกันอยู่ซักอย่างแต่เราไม่เข้าใจเลย ก็เลยบอกว่า “อิมาคิตะซังเกียว” เพื่อให้เพื่อนๆ อธิบายให้ฟัง

อ๋อ มันคือ TL;DR เวอร์ชันญี่ปุ่นสินะ

พอถึงตรงนี้คงมีคนคิดว่า อิมาคิตะซังเกียว คือ TL;DR หรือ Too long. Don’t read เวอร์ชันภาษาญี่ปุ่นสินะ

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

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

ส่วน TL;DR นั้นอาจจะใช้ในกรณีที่ผู้พูดรู้สึกว่า “ที่กำลังคุยกันอยู่ยาวมาก ไม่อ่านละ ไปสรุปมาให้หน่อย” หรืออาจจะใช้ในบริบทที่ผู้พูดรู้สึกว่าเนื้อหามันยาวมาก เลยต้องการจะสื่อว่า “สำหรับคนที่ขี้เกียจอ่าน เดี๋ยวจะสรุปให้ฟัง” ก็ได้

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

ตัวอย่างการใช้งาน

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

以上

เซต ssh ให้ใช้ Github ได้หลายแอคเคาท์

Sun, 31 Oct 2021 02:40:21 GMT

ปกติแล้ว Github แนะนำให้ใช้แอคเคาท์เดียวสำหรับทั้งเรื่องงานและเรื่องส่วนตัว แต่สำหรับบางกรณีที่ต้องใช้มากกว่า 1 แอคเคาท์ เช่นมีการใช้ dotfiles ร่วมกัน หรือใช้ Github สำหรับจดบันทึกส่วนตัว (เช่นใช้ Obsidian) ถ้าเป็นเมื่อก่อนอาจจะยอมใช้ HTTP Protocol แล้วใส่พาสเวิร์ดเอาแทนได้ แต่พอ Github เลิกรองรับการใช้งานพาสเวิร์ดก็เลยต้องมาออกแรงมากขึ้นหน่อยด้วยการเซต SSH config เพิ่ม

สมมติว่าเรามีแอคเคาท์ชื่อ my-personal-account กับ my-work-account

ให้สร้าง ssh public/private key pairs ของทั้งสอง เซฟในชื่อที่ต่างกัน เช่น my-personal-account กับ my-personal-account.pub และ my-work-account กับ my-work-account.pub
เลือกว่าจะให้แอคเคาท์ไหนจะให้เป็นแอคเคาท์หลัก กรณีนี้สมมติว่าให้ my-personal-account เป็นแอคเคาท์หลัก

ในไฟล์ ~/.ssh/config ให้กำหนดค่าแบบนี้

Host github.com
    HostName github.com
    User git
    AddKeysToAgent yes
    UseKeychain yes
    IdentityFile ~/.ssh/my-personal-account
    
Host github.com-work
    HostName github.com
    User git
    AddKeysToAgent yes
    UseKeychain yes
    IdentityFile ~/.ssh/my-work-account

สำหรับแอคเคาท์หลักก็ใช้คำสั่งตามปกติ แต่เวลาเราจะใช้งาน repo ที่เป็นของแอคเคาท์ทำงานก็ใช้วิธี git clone ด้วยการเติม -work เข้าไปท้าย github.com แบบคำสั่งข้างล่างนี้แทน โดยที่ตรง (your repo) นี่ก็ใส่เป็นชื่อ repo ที่ต้องการ
```
git clone git@github.com-work:(your repo)
```
เช่น
```
git clone git@github.com-work:my-work-accont/myrepo.git
```
คำสั่งอื่นๆ ก็ใช้งานตามปกติ

ข้อควรระวัง

ถึงแม้ว่าเราจะโคลนตัว repo มาได้แต่ว่าเวลาเรา commit code มันอาจจะเป็นชื่อและอีเมลที่เราใช้กับแอคเคาท์อื่นก็ได้ ดังนั้นคนที่กลัวว่าชื่อ/อีเมลจะปนกันก็ควรจะ ต้องตรวจสอบ .git/config ทุกครั้งหลังจาก clone ว่าตั้งค่า git.user และ git.email ถูกต้อง

2021 Facebook Outage

Mon, 04 Oct 2021 23:40:30 GMT

เมื่อวาน facebook.com รวมทั้งบริการอื่นๆ ของเฟซบุ๊กทั้ง Whatsapp, Instagram ล่มทั้งหมดเพราะมีข้อผิดพลาดเกิดขึ้นที่ระดับ BGP ถึงโลกจะสงบสุขชั่วคราว แต่เชื่อว่าวิศวกรของเฟซบุ๊กน่าจะวุ่นวายกันมากเป็นพิเศษ ระหว่างที่รอทางเฟซบุ๊กออก Post-mortem มา เราก็สามารถอ่านสรุปที่ Cloudflare สรุปเหตุการณ์จากมุมมองคนนอกเอาไว้ แทน

ในรายงานของ Cloudflare เล่ารายละเอียดว่าเกิดอะไรขึ้นที่ฝั่ง Cloudflare ในช่วงเวลาที่เกิดปัญหาขึ้น โดยก็ไม่ได้ลงลึกหรือเดาว่าเกิดอะไรขึ้นที่ฝั่งเฟซบุ๊ก กล่าวโดยสรุปก็คือมีการแก้ไขข้อมูลที่ BGP แล้วก็ทำให้ DNS ของฝั่งเฟซบุ๊กหายไปจากอินเทอร์เน็ต พอ DNS หายไปทุกอย่างที่ผูกกับ DNS ตัวนี้ก็หายไปด้วยรวมทั้ง https://status.fb.com/ ที่แม้จะอยู่บน Cloudfront ก็ได้รับผลกระทบไปด้วย

ส่วนที่คาดไม่ถึงของเหตุการณ์นี้ที่อยู่ในสรุปก็คือการล่มครั้งนี้ยังส่งแรงกระเพื่อมไปยังบริการ DNS ต่างๆ ด้วย คือพออุปกรณ์และแอปต่างๆ ไม่สามารถ resolve ชื่อโดเมนของเฟซบุ๊กไม่ได้ ผู้ใช้ก็อาจจะกดให้ refresh เพื่อลองใหม่ บวกกับตัวแอปเองก็อาจจะลอง resolve ชื่อโดเมนไปเรื่อยๆ ด้วยทำให้เกิดทราฟฟิกเพิ่มขึ้นมหาศาล จนทำให้บริการ DNS อย่าง 1.1.1.1 ของ Cloudflare หรือ 8.8.8.8 ของกูเกิลต้องรับภาระหนักมากขึ้น

ถ้าข้ามไปฝั่ง Krebs on Security ก็จะมีอธิบายสรุปพร้อมกับรายงานสดความคืบหน้าของเหตุการณ์แทน

รายได้เฉลี่ยของคนญี่ปุ่น

Sat, 06 Feb 2021 00:05:05 GMT

วันก่อนเห็นข่าวว่ารัฐบาลญี่ปุ่นจะมีการแก้กฏหมายเพื่อยกเลิกเงินสนับสนุนการเลี้ยงดูเด็กสำหรับครอบครัวผู้มีรายได้สูง คือมีรายได้ต่อปีเกิน 12 ล้านเยน ก็เลยสงสัยเกี่ยวกับรายได้เฉลี่ยของคนญี่ปุ่นขึ้นมา

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

จากผลสำรวจรายได้ครอบครัวที่มีขนาด 2 คนขึ้นไปของกระทรวงสาธารณสุข แรงงานและสวัสดิการญี่ปุ่นในปี 2019จะเห็นว่ารายได้เฉลี่ยต่อครอบครัวของคนญี่ปุ่นจะอยู่ที่ประมาณ 5.52 ล้านเยน โดยที่มีค่ามัธยฐานอยู่ที่ 4.37 ล้านเยน ส่วนจำนวนครอบครัวที่มีรายได้เกิน 12 ล้านเยนมีอยู่ประมาณ 7.2% เท่านั้นเอง

พอลองไปดูผลสำรวจเงินเดือนเฉลี่ยสำหรับพนักงานประจำของญี่ปุ่นที่จัดทำโดยเว็บไซต์หางาน doda สำหรับปี 2020 จะพบว่ารายได้เฉลี่ยอยู่ที่ประมาณ 4.1 ล้านเยน โดยที่ถ้าดูเฉพาะช่วงอายุ 40 - 60 ซึ่งเป็นช่วงอายุที่น่าจะมีครอบครัวแล้วก็จะมีรายได้เฉลี่ยอยู่ที่ 5.1 - 6.1 ล้านเยน

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

ส่วนที่เคยเห็นผ่านๆ ตอนดูหนังสือแนะนำบริษัทที่รับเด็กจบใหม่เมื่อหลายปีก่อน ก็จำได้ว่าเงินเดือนของเด็กป.โทจบใหม่ส่วนใหญ่อยู่ที่ประมาณ 220000 - 240000 เยน (คิดเป็นต่อปีคือประมาณ 2.6 - 2.8 ล้าน)

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

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

PS. รายได้ 12 ล้านเยน หักภาษีต่างๆ แล้วจะเหลือเทคโฮมประมาณ 8.6 ล้านเยน

CSS Zen Garden

Sun, 22 Mar 2020 15:00:00 GMT

CSS Zen Garden เป็นโปรเจคเก่ามากเปิดตัวมาตั้งแต่สมัยปี 2003 ตัวเว็บไซต์เองจะมี HTML อยู่หนึ่งหน้า แต่ผู้ใช้จะเลือกเปลี่ยน CSS เพื่อเปลี่ยนดีไซน์ของหน้านั้นได้โดยยังใช้ HTML เดิม ซึ่ง CSS พวกนี้ก็คือมาจากเว็บดีไซเนอร์ส่งเข้ามา

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

วันก่อนใน Hacker news มี คนเอาลิงค์นี้ไปโพสต์ แล้วในช่อง discussion ก็เกิดประเด็นถกเถียงกันมากว่า HTML กับ CSS เนี่ยมันควรจะแยกกันมั้ย

คือถ้ามาจากสาย CSS Zen Garden มาก่อนก็คงจะให้ความรู้สึกว่า HTML มันแสดงโครงสร้างของเอกสาร เพราะฉะนั้นมันก็ไม่ควรจะต้องมายุ่งเกี่ยวเลยกับการแสดงผลหรือเลย์เอาท์ของหน้าสิ ดังนั้นการเอาคลาสของ CSS สำหรับระบุหน้าตาไปใส่ใน HTML นี่มันก็เหมือนกับการเอา presentation กับ data มาปนกันมั่วไปหมด ใครนึกไม่ออกลองนึกถึงพวก css framework อย่าง Bootstrap ที่จะมีคลาสสำหรับกำหนดกริด กำหนดเลย์เอาท์ สี ช่องไฟอยู่เยอะแยะมากมาย

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

จริงๆ ก็คงเป็นเรื่องความชอบกับความเหมาะสมของแต่ละงานมากกว่า แต่เนื่องจากเริ่มรู้จัก CSS ก็จาก CSS Zen Garden ก็เลยชอบแนวทางของฝั่งนี้มากกว่า เพราะโค้ดของ html มันดูเป็นระเบียบเรียบร้อยสะอาดตาเข้าใจง่ายมากกว่าด้วย

แต่ทั้งหมดทั้งมวลถ้าให้สรุปเอง ก็คงจะได้ว่า HTML กับ CSS มันใช้ยากนั่นแหละ

Hacker News discussion: https://news.ycombinator.com/item?id=22627018

Meiji-jingumae Station

Sun, 06 Oct 2019 14:23:02 GMT

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

หลังจากหาด้วยกูเกิลดูก็ได้ความว่า ชื่อเดิมของสถานีตอนเปิดบริการในปี 1962 ใช้ชื่อแค่ว่า เมจิจิงกูมาเอะ โดยคาดว่าน่าจะต้องการไม่ให้ชื่อซ้ำกับสถานีฮาราจุกุของ JR ที่อยู่ใกล้ๆ กัน แต่เนื่องจากทั้งสองสถานีนั้นอยู่ในระยะที่เดินกันถึงและนับเป็นสถานีที่ใช้สำหรับเปลี่ยนสายระหว่างสายยามาโนเตะกับสายชิโยะดะมาตลอด ทำให้ในปี 2010 มีการตัดสินใจเพิ่มคำว่า [<Harajuku>] ลงไปในชื่อสถานีเพื่อเป็นการย้ำว่าสถานีนี้อยู่ในย่านฮาราจุกุมากขึ้น

ในปัจจุบันสถานีเมจิจิงกูมาเอะเป็นสถานีที่มีจำนวนผู้โดยสายขึ้นลงเป็นอันดับที่ 36 จากทั้งหมด 130 สถานีของโตเกียวเมโทร โดยในปี 2018 มีผู้ใช้งานเฉลี่ยต่อวันที่ 109528 คน ส่วนในปี 2010 ที่มีการเปลี่ยนชื่อสถานีนั้นมีผู้โดยสารขึ้นลงเฉลี่ย 74693 คนต่อวัน ลดลงจากปี 2009 ที่มีผู้โดยสารขึ้นลงเฉลี่ย 75434 คนต่อวันหรือลดลงประมาณ 1%

Building Control Plane

Wed, 28 Aug 2019 00:05:05 GMT

Longdo Dict Chrome Bookmarklet

Mon, 22 Jul 2019 15:00:00 GMT

อันนี้เป็น Bookmarklet ใช้สำหรับเวลาจะเปิดหาความหมายคำจาก Longdo Dict

ด้วยความที่ขี้เกียจเขียนให้เป็น Extension ของ Chrome ก็เลยทำมาไว้เป็น Bookmarklet ของจาวาสคริปต์แทน เวลาใช้ก็ Highlight ประโยคแล้วก็กดที่ปุ่ม Bookmarklet หรือว่ากดที่ Bookmarklet แล้วก็พิมพ์คำที่ต้องการก็จะเปิดหน้าต่างใหม่ของ Longdo Dict ให้เอง

ตอนทำออกมาใหม่ๆ จำได้ว่าทาง Longdo Dict ก็เคยเอาไปแชร์ไว้รอบนึงแล้ว แต่วันก่อนเข้าไปเปิดดูปรากฏว่าลิงค์เดิมที่เก็บโค้ดอันนี้ไว้มันใช้งานไม่ได้แล้ว เลยขอเอามาแปะใหม่ที่นี่แล้วกัน วิธีติดตั้งก็คือลากข้อความข้างล่างไปแปะเป็น Bookmark ได้เลย

javascript:void(q=window.getSelection?window.getSelection():(document.getSelection?document.getSelection():(document.selection?document.selection.createRange().text:'')));if(q=='')void(q=prompt('Enter a word',''));if(q){void(ldwin=window.open('http://dict.longdo.com/mobile.php?search='+encodeURIComponent(q),'ldwin','width=600,height=600,resizable=yes,scrollbars=yes,toolbar=no,location=no,directories=no,status=yes,menubar=no,copyhistory=no'));void(setTimeout('ldwin.focus()',1));};

ชื่อ

Fri, 24 May 2019 15:00:00 GMT

คุยกับพี่ที่ทำงานเรื่องชื่อไป เลยขอจดคำศัพท์เกี่ยวกับชื่อไว้เล่นๆ

ชื่อต้น ชื่อกลาง ชื่อท้าย – อันนี้น่าจะมาจากคำว่า first/middle/last name
ชื่อตัว – อันนี้เคยได้เห็นใช้ในหนังสือภาษาอังกฤษ หมายถึงชื่อ
上の名前 (ความหมาย: ชื่อบน) – นามสกุล อันนี้น่าจะเพราะว่าภาษาญี่ปุ่นเวลาเขียนแบบบนลงล่าง นามสกุลที่มาก่อนก็เลยอยู่ข้างบน
下の名前 (ความหมาย: ชื่อล่าง) – ชื่อตัว เหตุผลเดียวกับข้างบน
姓名（せいめい）・氏名（しめい）– ชื่อนามสกุล
名前（なまえ）- ชื่อ-นามสกุล หรือชื่ออย่างเดียวก็ได้
名（な）– ชื่อ
名字・苗字（みょうじ）– นามสกุล
芸名 – Stage name หรือพวกนามแฝง
本名（ほんめい、ほんみょう） – ชื่อจริง (ที่ไม่ใช่ stage name หรือพวกชื่อในวงการ)