Back to top

Planet TLWG

Error message

Deprecated function: The each() function is deprecated. This message will be suppressed on further calls in menu_set_active_trail() (line 2404 of /usr/share/drupal7/includes/menu.inc).
Subscribe to Planet TLWG feed
Planet TLWG - http://linux.thai.net/planet
Updated: 1 hour 35 min ago

bact: คนทำงานด่านหน้า-งานจำเป็น ที่จะได้รับวัคซีนลำดับต้นๆ มีใครบ้าง

11 April, 2021 - 18:55

ลองไล่ๆ ดูในเว็บไซต์หน่วยงานที่รับผิดชอบด้านนโยบายวัคซีนของประเทศต่างๆ ว่าใครคือ “คนทำงานด่านหน้า” (front-line workers) หรือ “คนทำงานสำคัญและจำเป็น” (essential workers) ที่ไม่ใช่เจ้าหน้าที่ด้านสุขภาพบ้าง (กลุ่มสุขภาพเป็นกลุ่มที่เรานึกถึงและได้ยินกันบ่อยๆ อยู่แล้ว) และใครคือกลุ่มที่จะได้รับวัคซีนลำดับต้นๆ ในวิธีคิดของประเทศนั้นๆ

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

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

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

กรมควบคุมโรคสหรัฐ (CDC) ใช้เกณฑ์ ACIP Categories of Essential Workers ซึ่งแบ่งเป็น (1a) Essential Healthcare Workers (คนทำงานที่จำเป็นด้านสุขภาพ ระบุชัดว่าทั้งที่ได้รับค่าจ้างและไม่ได้รับค่าจ้าง) (1b) Frontline essential workers (Non-Healthcare) (คนทำงานที่จำเป็นที่อยู่ด่านหน้า ที่ไม่ใช่สายสุขภาพ ซึ่งทำงานในสภาพแวดล้อมที่ต้องอยู่ใกล้ชิดเพื่อนร่วมงานหรือคนทั่วไป เลี่ยงไม่ได้) และ (1c) Other essential workers (อื่นๆ ตามกำหนด)

รัฐบริติชโคลัมเบียในแคนาดา กำหนด Front-line priority workers มาตามภาพ มีทั้งครูโรงเรียนเด็กเล็ก คนดูแลเด็ก พนักงานไปรษณีย์ พนักงานร้านชำ คนทำงานในภาคการผลิต คนทำงานเรือนจำ คนทำงานขนส่งข้ามแดน ฯลฯ

ส่วนไอร์แลนด์จะเน้นที่คนทำงานด่านหน้าด้านสุขภาพเป็นหลัก และมีเพิ่มเติมคือ “key workers essential to the vaccine programme” คนทำงานที่สนับสนุนการจัดหาและกระจายวัคซีน และการฉีดจะเน้นกลุ่มเปราะบาง คนป่วย (มีการกำหนดชื่อโรคและเงื่อนไขของอาการอย่างชัดเจน) และผู้สูงอายุ ก่อนกลุ่มอื่น และหลังจากที่กลุ่มจำเป็นอื่นๆ ได้รับวัคซีนกันไปแล้ว ลำดับที่เหลือจะมีลักษณะไล่ตามกลุ่มอายุ

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

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

ต้นเดือนมีนา 2564 ตอนที่สิงคโปร์ประกาศขยายกลุ่มที่ได้รับวัคซีน ก็ระบุถึงกลุ่มอย่างคนทำงานที่เสี่ยงสัมผัสสูงหรือมีโอกาสส่งต่อได้มาก “Essential workers with higher risk of exposure and onward transmission” ซึ่งรวมครูและเจ้าหน้าที่ในโรงเรียนเด็กเล็กด้วย โดยระบุว่าเนื่องจากยังไม่มีวัคซีนสำหรับเด็กเล็ก การฉีดคนอื่นในโรงเรียนจึงเป็นวิธีป้องกันเด็กที่ทำได้ในตอนนี้

นอกจากนี้ก็มีกลุ่มคนงานข้ามชาติ “Migrant workers living in dormitories” เนื่องจากคนงานข้ามชาติเหล่านี้อาศัยอยู่ในหอพักขนาดใหญ่ที่มีคนมาก (ประกาศของรัฐบาลไม่มีคำว่า “แออัด” แต่ก็นั่นแหละ เข้าใจกันได้ ว่ามันเสี่ยงเพราะคนอยู่เยอะด้วย)

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

ดูของหลายๆ ที่แล้ว แล้วก็น่าจะเป็นการประเมิน/จัดลำดับตาม โอกาสเกิด และ ความเสียหายที่จะเกิด เช่น

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

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

ของไทยเองก็มีสิ่งที่คล้ายๆ เกณฑ์อยู่ โดยอิงกับช่วงการฉีด 3 ระยะ (ซึ่งแบ่งช่วงตามปริมาณวัคซีนที่มี) แล้วก็ระบุกลุ่มที่จะได้รับวัคซีนในช่วงนั้นๆ ไว้กว้างๆ เช่น “ผู้ประกอบอาชีพที่มีโอกาสสัมผัสกับคนจำนวนมาก” แต่ไม่ได้มีรายละเอียดว่ามีอาชีพอะไรบ้าง (ข้อมูล 27 ม.ค. 2564)

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

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

เผยแพร่ครั้งแรก 9 เมษายน 2564 บนเฟซบุ๊ก

The post คนทำงานด่านหน้า-งานจำเป็น ที่จะได้รับวัคซีนลำดับต้นๆ มีใครบ้าง first appeared on bact' is a name.

bact: คิดเงิน “ตามตัวอักษร” แฟร์ไหม?

11 April, 2021 - 18:21

เช็คอะไรนิดหน่อย ไปเจออันนี้ วิธีการคิดเงินของ Google Cloud Translation API ก็แฟร์ระดับหนึ่งนะ คือคิดตามจำนวนตัวอักษร (code point) แทนที่จะคิดตามปริมาณข้อมูลจริงๆ (byte)

Charged characters

To calculate usage, Google counts usage on a per character basis, even if a character is multiple bytes. Each character corresponds to a code point.

You are charged for all characters that you include in a Cloud Translation request, even untranslated characters. This includes, for example, whitespace characters. If you translate <p>こんにちは</p> to English, it counts as 12 characters for the purposes of billing.

Google also charges for empty queries. If you make a request without any content, Google charges one character for the request.

—-

คือในทางคอมพิวเตอร์ มาตรฐานตัวอักษรที่แพร่หลายในปัจจุบัน คือมาตราฐาน Unicode และวิธีการจัดเก็บตัวอักษรที่นิยมและเข้ากันได้กับแอปบนอินเทอร์เน็ตต่างๆ ก็คือ UTF-8 ซึ่งในตัวอักษรในแต่ละระบบการเขียนอาจใช้จำนวนไบต์ไม่เท่ากัน ตัวละตินที่ไม่มีเครื่องหมายประสม (อย่างที่ใช้ในภาษาอังกฤษ มาเลย์ อินโด) จะใช้เพียง 1 ไบต์ต่อ 1 ตัวอักษร (code point) ส่วนตัวอักษรไทยจะใช้ 3 ไบต์ต่อ 1 ตัวอักษร

จากการตัดสินใจในขั้นการออกแบบ มันเป็นไปได้ที่จะมีการเลือกปฏิบัติ มีความ “ไม่เท่าเทียม” หรือความ “ไม่ปลอดภัย” หรือความใดๆ ที่ถ้าเป็นไปได้ก็ไม่อยากให้มี ฝังอยู่ในระบบสถาปัตยกรรมของระบบ บางอย่างไม่ได้อยากให้มี แต่ด้วยข้อจำกัดของทรัพยากรที่มีจำกัดกว่าหรือสมมติฐานของบริบทการใช้งานในตอนที่ออกแบบ ก็เลยตัดสินใจว่าใช้แบบนี้ไปละกัน มันโอเคสำหรับตอนนั้น – แต่พอเวลาผ่านไป ย้อนกลับไปพิจารณา ก็อาจตัดสินใจอีกแบบได้ (จะมีโอกาสแก้ไขไหมก็อีกเรื่อง)

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

แต่ต่อมาเมื่อสมมติฐานความปลอดภัยนั้นไม่เป็นจริงแล้ว หรือข้อจำกัดทางเทคโนโลยี/เศรษฐกิจนั้นได้คลายลงแล้ว ก็มีการคิดวิธีเข้ารหัสลับให้กับข้อมูลขึ้นมา โดยยังทำงานอยู่บนโปรโตคอลเดิม มีความเข้ากันได้กับระบบเก่าๆ (backward compatible)

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

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

เมื่อระบบเหล่านี้ขยายใหญ่ขึ้น มีการนำไปใช้กับหลากหลายภาษาวัฒนธรรรมมากขึ้น มีผู้ใช้จำนวนมากขึ้น จากหลากหลายภูมิหลังขึ้น ใช้กับหลากหลายบริบทความปลอดภัยมากขึ้น สมมติฐานหลายๆ อย่างที่เคยใช้ได้ ก็เปลี่ยนไป

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

เช่น เดิมใช้ 7 บิตเพื่อแทนชุดตัวอักษร 128 ตัว ก็ขยายมาเป็น 8 บิต 16 บิต ฯลฯ โดยพยายามทำให้มันรองรับระบบเดิมอยู่ โดย 128 ตัวแรก ยังใช้ตัวอักษรชุดเดิมอยู่อะไรงี้ ซึ่งวิธีที่เก็บตัวอักษรที่ใช้บนอินเทอร์เน็ตส่วนใหญ่ตอนนี้ใช้วิธีนี้อยู่ ชื่อมาตรฐานคือ UTF-8

UTF-8 นี่เป็นวิธีการแปลงรหัสเพื่อบันทึกตัวอักษรแบบที่เรียกว่า “variable-width encoding” คือ ตัวอักษรแต่ละตัวอาจใช้จำนวนข้อมูล (คิดเป็นไบต์) ในการเก็บไม่เท่ากัน — พวกตัวอักษรละตินและสัญลักษณ์พื้นฐาน 128 ตัวแรก จะใช้ 1 ไบต์ ตัวละตินอื่นๆ เกือบทั้งหมดที่เหลือ (ซึ่งภาษาจำนวนมากในยุโรปใช้ รวมถึงภาษาอย่างเวียดนาม ก็ใช้ตัวเขียนเหล่านี้) รวมถึงตัวอักษรกรีก ฮีบรู อารบิก คอปติก พวกนี้ใช้ 2 ไบต์ ตัวอักษรที่เหลือเกือบทั้งหมดจะใช้ 3 ไบต์ ในกลุ่มนี้มีตัวอักษรจีน ญี่ปุ่น เกาหลี ไทย รวมอยู่ด้วย ส่วนพวก 4 ไบต์นี่จะเป็นตัวอักษรที่ไม่พบบ่อยนัก หรือเป็นส่วนขยาย/กรณีพิเศษของตัวอักษรบางตัว

วิธีคิดของคณะออกแบบ UTF-8 ก็คือ ตัวอักษรไหนมีแนวโน้มจะใช้บ่อย ใช้มาก ก็พยายามให้ใช้จำนวนไบต์น้อยๆ เพื่อที่ว่าในภาพรวมจะได้ประหยัดพื้นที่จัดเก็บ เว้นเสียว่าจะทำไม่ได้จริงๆ อย่างกลุ่มตัวอักษรจีน​ญี่ปุ่นเกาหลี (CJK) ที่จำนวนตัวอักษรมันเยอะ จะยัดลง 2 ไบต์ก็ไม่ไหว ก็ใช้ 3 ไบต์ไป

ซึ่งในแง่นี้ การให้ตัวอักษร ASCII ใช้เพียง 1 ไบต์ ก็เข้าใจได้มาก ๆ เพราะตัวอักษรในชุดนี้ถูกใช้เป็นคำสั่งและคำสำคัญต่างๆ ในโปรโตคอลการรับส่งข้อมูลและมาตรฐานข้อมูลอื่น ๆ ในระดับพื้นฐานของคอมพิวเตอร์ ถ้าเกิดตัวอักษรชุดนี้ใช้จำนวนไบต์เยอะ ทุกอย่างในระบบก็จะพองขึ้นทันที ซึ่งผลพลอยได้ก็คือ พวกภาษาที่ใช้ตัวอักษรที่อยู่ในกลุ่มตัวละติน (A-Z, a-z) ก็เลย “โชคดี” ไปด้วย (หรือมองอีกมุม ก็เป็นเพราะคนที่ใช้ภาษาที่ใช้อักษรละติน เป็นคนกำหนดมาตรฐานคอมพิวเตอร์ไง ผลที่ตามมาเลยเป็นแบบนี้)

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

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

คำว่า “บ่อย ๆ” นี่เอาอะไรวัด จากมุมของใคร หรืองานแบบไหน

แต่เอาล่ะ มาตรฐานมันก็กำหนดมาแบบนี้แล้ว ไปแก้อะไรไม่ได้ (จริงๆ ก็แก้ได้ แต่ต้องไปตามแก้ข้อมูลที่ถูกจัดเก็บไปแล้วทั้งหมด ก็ลำบากมากๆ อยู่) ก็เลยกลายเป็นว่ามีบางภาษา พอออกมาเป็นรูปตัวเขียน ต้องใช้พื้นที่ในการจัดเก็บมากกว่าภาษาอื่น เพราะต่อ 1 ตัวอักษร ใช้จำนวนไบต์มากกว่า

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

วิธีการคิดค่าบริการตามจำนวนตัวอักษร แทนที่จะเป็นจำนวนไบต์ข้อมูลที่จะต้องใช้เก็บตัวอักษรนั้น ก็เลยถูกมองได้ว่าแฟร์ขึ้นมาอีกนิดนึง

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

หรือถ้าไปให้สุดๆ เฮ้ย บางภาษา 1 ตัวอักษร มันเก็บความหมาย อุ้มความหมายเอาไว้ได้เยอะกว่า 1 ตัวอักษรในอีกภาษา ภาษาญี่ปุ่นเขียน 1 ตัว 空 ภาษาไทยต้องเขียน 7 ตัว เพื่อจะได้ความหมายว่า ท้องฟ้า เท่ากัน แบบนี้คนไทยก็ต้องจ่ายแพงกว่าคนญี่ปุ่นรึเปล่า (แบบ 280 ตัวอักษรบนทวิตเตอร์ คนจีนแทบจะเขียนเรื่องสั้นได้แล้ว คนไทยแค่รายงานข่าวอาจจะไม่พอ) แบบนี้การคิดค่าบริการตามตัวอักษรก็ไม่แฟร์อยู่ดีปะ

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

ตราบใดที่การสร้างมันเกิดการกระบวนการตัดสินใจเลือก การเลือกปฏิบัติมันมีอยู่แน่ๆ ในผลงานทางวิศวกรรม

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

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

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

เผยแพร่ครั้งแรก 7 เมษายน 2564 บนเฟซบุ๊ก

พอโพสต์เรื่องข้างต้นจบ ก็นึกถึงอีกประเด็นในสัปดาห์ก่อนหน้า ที่คนพูดถึงบทความ When Binary Code Won’t Accommodate Nonbinary People ซึ่งก็คิดๆ ไปก็น่าจะเป็นเรื่องของ encoding นี่อยู่เหมือนกัน เป็นการเอาการจัดประเภทฝังลงไปในระบบ

ถ้าได้อ่านในบทความนั้น คิดว่าหลักใหญ่ใจความประเด็นมันคือเรื่องการออกแบบตัวระบบ — ทั้งระดับโครงสร้างพื้นฐานและระดับส่วนติดต่อผู้ใช้ — ไม่ว่าจะเป็น database schema ช่องหรือปุ่มที่มีให้กดในหน้าจอ UI หรือวิธีการทำ data validation ที่ทำให้ข้อมูลที่อยู่นอกเหนือไปจากที่ผู้ออกแบบระบบอนุญาต มันกรอกไม่ได้ รวมไปถึงคู่มือใช้งาน/การอบรมการใช้งานที่ทำให้เจ้าหน้าที่ที่เป็นผู้กรอกยึดอยู่กับคุณค่าบางอย่าง แม้ตัวระบบจะไม่ได้บังคับ (ในระบบที่ตัวเจ้าของข้อมูลไม่ได้เป็นผู้กรอกเอง)

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

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

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

ซอฟต์แวร์เป็นสถาปัตยกรรมที่กำหนด (อนุญาต/ไม่อนุญาต) ทางที่เราจะใช้ชีวิต{ใน/กับ/ด้วย}สภาพแวดล้อมนี้ได้ ไอเดียเดียวกับที่เลซสิกเสนอว่า code is law น่ะแหละ

เผยแพร่ครั้งแรก 31 มีนาคม 2564 บนเฟซบุ๊ก

The post คิดเงิน “ตามตัวอักษร” แฟร์ไหม? first appeared on bact' is a name.