เมื่อเดือนธันวาคมที่ผ่านมารัฐสภาบัลแกเรียตั้ง Bozhidar Bozhanov เข้าเป็นรัฐมนตรีรัฐบาลอิเล็กทรอนิกส์ ภายใต้รัฐบาลของ Kiril Petkov จุดที่น่าสนใจคือ Bozhanov นับเป็นโปรแกรมเมอร์ที่อยู่ใน Stackoverflow มายาวนาน คะแนน reputation ของเขาสูงถึง 566,945 คะแนน และได้รับ gold badge ถึง 138 รายการ เป็นผู้ใช้ระดับ top 0.01% ของเว็บ
แม้จะคะแนนสูง แต่ที่จริงแล้ว Bozhanov ก็แทบไม่ได้ตอบคำถามบน Stackoverflow มาหลายปีแล้ว โดยคำตอบล่าสุดที่เขาเข้าไปตอบอยู่ที่ปี 2015 แม้จะยังเข้าไปถามคำถามอยู่บ้างเนืองๆ
ตัว Bozhanov เป็นโปรแกรมเมอร์ทำงานมาหลายบริษัท และแตะงานการเมืองด้วยการเป็นที่ปรึกษารองนายกรัฐมนตรีบัลแกเรียมาก่อน ก่อนจะไปตั้งบริษัท LogSentinel อยู่สี่ปี และเพิ่งลาออกมารับตำแหน่งรัฐมนตรี
บล็อคล่าสุดของเขาหลังรับตำแหน่ง บ่นเรื่องบั๊กวันที่บน Microsoft Exchange ว่าไม่ควรมีใครคิดฟอร์แมตใหม่อีก ควรใช้ ISO-8601, epoch, หรือ RFC2822 ก็เพียงพอแล้ว
Get latest news from Blognone
Follow @twitterapi
Comments
ใกล้ถึงเวลาแล้วล่ะ ผมว่าในอนาคตข้างหน้าเมื่อเข้าสู่ยุค digital น่าจะเป็นเรื่องปรกติที่คนสาย IT จะเข้ามาทำงานในรัฐบาลของทุกประเทศ แต่ก็มีข้อควรระวังเหมือนกันว่าคน IT มันก็มีหลายสาย อาจต้องเลือกสายที่มีประสบการณ์ในด้านนโยบาย และบริหารงานด้วย ไม่ใช้เลือกสาย Technical จ๋า ซึ่งบางครั้งอาจทำเรื่องง่ายให้กลายเป็นเรื่องยากได้เหมือนกัน
ถ้ามาแนว เจ้าของช่อง แบบไต๋ ก็ไม่เอานะครับ กลัวจะเป็นแบบนั้น
ผมว่าน่าจะแนวคุณกระทิง หรือคนอื่นที่มีบุคลิกคล้ายกันมากกว่า ต้องมีความรู้เทคนิค รู้ว่าภาพรวมคืออไร ภาพย่อยคืออะไร เลือกใช้คนเป็น วางนโยบายระยะยาวได้ PR ประชาสัมพันธ์ อธิบายสิ่งที่ยากให้ประชาชนเข้าใจง่ายได้ เข้าถึงเครือข่ายสื่อมวลชน เข้าผู้ใหญ่ที่ต้องประสานงานด้วยได้ ไม่ไปชวนทะเลาะ ถ้าเป็นแนวนี้น่าจะเป็นสเปคที่ยอมรับได้ทุกฝ่าย
แต่ถ้าเมืองไทย เอาตามความเป็นจริง ก็คงต้องไปดึงคนจากแบงค์ชาตินั่นแหล่ะครับ เพราะคุ้นเคยกับระบบราชการไทยอยู่แล้ว แต่ก็มีแนวคิดทันสมัย รู้จักผ่อนสั้นผ่อนยาว
กระทิง อ่ะนะ เหอะ ก็ปั่นกันไป
มีใครแนะนำไหมล่ะครับ ผมแค่บอกรวมๆ คนสายบริหารส่วนใหญ่ไม่ค่อยมีคนชอบหรอกเพราะจุดแข็งของเขาคือการเลือกใช้คน ง่ายๆ คือมีศิลปะในการหลอกใช้คนโดยที่คนที่ถูกใช้ไม่รู้สึกว่าถูกหลอกใช้อยู่นั่นแหล่ะ ผมเองก็เลือกคนแบบนี้มาบริหารบริษัท เพราะมันทำให้ทุกคนทำงานร่วมกันได้โดยไม่ทะเลาะกัน เขาทำอะไรแทบไม่เป็นเลย เขียนโค๊ดยังไม่ได้เลย แต่ทำให้งานหลักหลายสิบล้าน คนหลายทีมทำงานจนเสร็จได้คุณคิดว่าไงล่ะ
มีพี่หลายคนมาถามว่าทำไมเลือกคนแบบนี้มาบริหาร ทำไมไม่บริหารเอง ผมก็ได้แต่หัวเราะ หึ หึ ผมก็แค่อยากมีชีวิตที่สงบ มีเวลาไปทำงานที่ตัวเองชอบ บ้างก็แค่นั้นแหล่ะคือคำตอบของผม
นายอาร์มครับ #ผิด
คือแบบไหนครับ ผมไม่ทราบจริงๆ พอจะมี link ให้อ่านหรือดูไหมครับ ขอบคุณครับ
บัลแกเรียผมนึกถึงแค่สองอย่าง
1. โยเกิร์ต
2. ฮริสโต้ สตอยช์คอฟ
ความเห็นน่าสนใจ แต่ผมไม่เห็นด้วยนะ
datetime format ใหม่ควรมี แต่ยังไม่ต้องรีบ ยังมีเวลามี 16 ปี (2038)
ทำไมต้องมี datetime format ใหม่หรอครับ และทำไมถึงใช้ได้แค่ 2038
อย่าง ISO 8601 ที่อยู่ใน format 2022-02-03T12:50:25+07:00 มันก็ใช้ได้ยาวถึงปี 9999 เลยนะครับ (ยกเว้นจะเปลี่ยนวิธีการนับปฏิทินหรือการนับเวลา)
น่าจะหมายถึง UNIX Time ที่ออกแบบไว้ 32bit ครับ
ผมหมายถึง epoch มันจะเก็บเป็น second ใน int
ถ้าใช้ signed int32 (ส่วนมากจะใช้อันนี้) มันจะเก็บได้ถึง 2147483647
ตอนนี้ epoch มันอยู่ที่ 1643868142
ฉะนั้น (2147483647 - 1643868142) / (60 * 60 * 24 * 365) =~ ประมาณ 16 ปี
มันจะ overflow
ถ้าเข้าใจไม่ผิดมันน่าจะเป็นปัญหาที่ Software นะครับเพราะส่วนใหญ่เก็บกันที่ 32bit ก็อยู่ได้ถึง 2038 แล้วอย่างแค่ขยายให้เป็น 64 bit ก็ไม่น่ามีปัญหารึเปล่า หรือผมเข้าใจผิด ? ซึ่งแน่นอนว่าใครที่ทำซอฟต์แวร์วันนี้ คงไม่ maintain โค๊ดชุดเดิมไปอีก 16 ปีต่อจากนี้แน่นอน ถึงตอนนั้นก็ต้องเขียนใหม่อยู่ดี
ถูกครับ แต่อย่าลืมว่า
software มันไม่ได้มีแค่ใน computer
เดี๋ยวนี้ใน รถยนต์ ตู้เย็น โทรทัศน์ ก็มี OS นี้ก็ใช่
มันไม่ได้เปลี่ยนกันง่ายๆ
ผมคุ้นๆ ว่าปัจจุบันระบบที่ใช้ floppy disk ยังมีอยู่เลย อ่านจาก blognone นี่ล่ะ
อ๋อ ถ้าเรื่อง unix time 32 bit ก็เป็นได้ครับ แต่ผมว่าใกล้ ๆ เดี๋ยวก็คงค่อย ๆ ทยอยปรับระบบกันให้เป็น int64 กัน แต่ต้องใช้เวลาหลายปี เพราะกระทบเยอะ ทั้งระบบ file system (อันนี้ต้องแก้ระดับ OS กันเลย), database (database ผมว่าไม่กระทบมาก เพราะถ้า up version ตัว data ยังคงเดิม แค่ขยายเนื้อที่เก็บมากขึ้น), ส่วน application อื่น ๆ ก็ถ้าหากใช้มาตรฐานตัวอย่าง (อย่างเช่นใช้ time_t) ก็ update compiler และก็ compile ใหม่ test ใหม่สักหน่อย แต่ถ้าหากกำหนดชนิดตัวแปลเอง อาจจะต้องหาจุดแก้เพิ่มขึ้น
หรือจริง ๆ เปลี่ยนจาก signed int32 เป็น unsigned int32 ก็จะกระทบน้อยลง (bit หน้าสุด) แต่ถ้าระบบไหนเช็คค่าลบ ก็ซวยละครับ
ทั้งนี้ทั้งนั้นต้องอยู่ที่การกำหนดมาตรฐานตัวนี้แหละครับ
ปล. เรื่องนี้เกี่ยวกับ datetime structure ครับ ถ้า datetime format น่าจะหมายถึงรูปแบบการแสดงผลมากกว่า
พูดถึง datetime format นี่บางทีก็ปวดหัวกับ DEV บางคนที่ไม่สนใจ ISO มากครับ ถุ้าใช้ฟังก์ชัน stringify อย่างน้อยก็แปลงให้เป็น ISO แล้วสบายหน่อยเพราะรองรับทุกภาษา แต่ประเภทที่ส่งเป็น string นี่ส่งกันแบบตามใจฉันสุดๆ บางคนมาทั้ง DD/MM/YY, DD/MM/YYYY, YYYY/MM/DD ต้องมาแปลงให้แสดงผลได้ทั้งหน้าบ้านและหลังบ้าน ถ้าจะส่งกันแบบนี้จริงๆอย่างน้อยขอ YYYY-MM-DD เถอะ อย่างน้อยก็โยนเข้า Mysql ได้
ปัญหาแบบนั้นธรรมดาครับ เจอพวกแปลง iso date แปลง timezone ด้วยการตัด string ที่บอก timezone ออก แล้ว + 7 ชั่วโมงดื้อๆ แล้วจะหนาว
555 อันนี้ฮาจริงครับ เจอมากับตัว
เรื่อง date/time format นี่น่าจะคุยกันยาว หลายระบบก็หลายปัญหา
..: เรื่อยไป
เป็นเรื่องที่อดีตหัวหน้าผมต้องโทรไปด่า vendor ว่า "ถ้าม*งส่งค่าวันที่เป็น ISO-8601 ไม่ได้ ก*จะไม่ซื้อของจากม*งอีกต่อไป" มาแล้วครับ
โหดเหมือนกันแฮะ แค่ Format ไม่ได้ก็ไม่ยอมแล้ว
ปล ภาพแมวน่ารักดีแฮะ อันนี้เป็นแวมเลี้ยงเองหรือมาจาก Internet ครับ
ความล้มเหลว คือจุดเริ่มต้นสู่ความหายนะ มีผลกระทบมากกว่าแค่เสียเงิน เวลา อนาคต และทรัพยากรที่เสียไป - จงอย่าล้มเหลว
ปัญหาคือค่าเวลาที่ได้มาก่อนโทรไปด่ามันดันเป็น local time ของเครื่องที่ submit ข้อมูลมา แล้วเอามาหาว่าใครส่งข้อมูลมาก่อนไม่ได้ (จริงๆ มันควรเอาเวลาที่ข้อมูลมาถึง server มาให้) แถมเคยโทรไปแจ้งให้แก้ปัญหาแบบนี้แล้ว vendor ที่ว่าก็ยังไม่แก้จนต้องโทรไปด่าครับ
ปล. แมวผมเองครับ
ความเห็นคงต่างกันได้ แต่ถ้าคุยกับแบบวิศวกรก็ต้องถามว่าอยากสร้าง format ใหม่ไปทำไม มีประโยชน์อะไร คุ้มกับบั๊กต่างๆ ที่จะเกิดขึ้น (parser เดิมๆ ทดสอบมาเยอะมากแล้ว รองรับ use case หลากหลาย ทั้ง timezone, localtime ฯลฯ) บ้าง หรือทำเพราะแค่อยากทำใหม่เฉยๆ
lewcpe.com, @wasonliw
566,895 => 566,945
ละเอียดยิบ 5555555