rawitat.com | Rawitat Pulam

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

แต่ว่าดูนี่ซะก่อน

อ่านได้ชัดเจน สวยงามมาก … ตอนที่ผมพิมพ์ตอนแรก อึ้งไปสามสิบวินาที ก่อนจะร้อง “เฮ้ย จะบ้าเรอะ!” แบบไม่เกรงใจคนรอบข้าง .. ไม่ทราบว่าท่านไปจ้างโปรแกรมเมอร์ที่ไหน ทำในงบประมาณหลักกี่ล้านครับท่าน? ยังไม่พอนะครับ ข้างล่าง ผมยังพบสิ่งนี้

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

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

ผู้ถาม: อาจารย์เว็บแบบไหนที่แตกต่างๆ
ผู้ถาม: ขอคำแนะนำหน่อยนะคะ
ผู้ถาม: พอดีเพื่อนเขียนเว็บให้บริษัทน่ะ
ผม: แล้วทำไมต้องแตกต่าง?
ผู้ถาม: แต่ไม่อยากจำเจอยู่กับรูปแบบเดิมๆๆ
ผม: มาอีกล่ะ พวกทำงานเอารูปแบบเป็นหลัก จะรูปแบบเก่า รูปแบบใหม่ ถ้าไม่ได้วิเคราะห์เรื่อง function และ usage เป็นหลัก มันจะทำได้ไง
ผู้ถาม: แต่คือว่าเขาแค่ตอ้งการดีไซต์และส่วนเรือ่งนั้นเขาคงทำเองอ่ะ
ผู้ถาม: ก้อแค่ออกแบบอะ
ผม: เว็บไซต์ไม่สามารถ design หน้าตาได้ หากไม่ design function ครับ
ผม: มันเหมือนกับคุณอยากจะออกแบบ “หน้าตา” ของรถยนต์ โดยไม่กำหนดว่า รถคันนี้ จะต้องวิ่งในที่แบบไหน บรรทุกอะไร กลุ่มเป้าหมายคืออะไร
ผม: คุณอาจจะคิดว่า หน้าตารถสปอร์ตมันเท่ห์ดี
ผม: แต่รถตู้ที่ออกแบบโดยใช้ concept รถสปอร์ต มีแต่ห่วยกับห่วย
ผม: ว่างั้นเถอะ
ผม: ไม่ได้กวนตีนหรือหลบเลี่ยงในการตอบ แต่ด้วยจรรยาบรรณ ไม่สามารถออกแบบเฉพาะหน้าตาได้ครับ หากคุณเคารพวิชาชีพตัวเอง ในฐานะนักออกแบบเว็บไซต์
ผู้ถาม: แต่มานก้อเปงส่วนหนึ่งหนิ
ผม: ลำดับก่อนหลังมีผลครับ
ผม: เอางี้ ผมให้คุณเลือกชุด จะพาออกงาน คุณจะเลือกชุดอะไร? ยังไง?
ผู้ถาม: ก้อต้องดูงานก่อนค่ะ
ผม: ใช่มั้ย
ผม: คุณต้องทราบว่า “งานอะไร แขกที่จะต้องไปพบ เป็นคนระดับไหน ต้องดู look เป็นยังไง ฯลฯ” ใช่มั้ย
ผม: ก็แบบเดียวกับการออกแบบเว็บไซต์น่ะแหละครับ
ผู้ถาม: แต่งานนี้เปงวัตถุดิบทางอุตสาหกรรม
ผู้ถาม: แต่ลูกค้าบอกว่าไม่อยากให้ธุรกิจมากเกิน
ผม: ถามคนอื่นเถอะครับ
ผม: คนที่ไม่ได้มีมาตรฐานในการทำงาน และมีจรรยาบรรณในการักษามาตรฐาน มีเยอะครับ
ผู้ถาม: ค่ะ
ผม: เหมือนสร้างตึกครับ ถ้าผมเป็นนักออกแบบ สถาปนิก ผมคงไม่สามารถบอกได้ว่า “ตึกนี้สวย ตึกนี้สวย ตึกนี้แปลก เอาแบบนี้ ผสมกับแบบนี้ ผสมกับแบบนี้ ฯลฯ” โดยไม่ดูว่า “แล้วมันเป็นตึกอะไรวะ ใครจะอยู่วะ เอาไปทำอะไรวะ คนเดินเข้าออกเยอะมั้ยวะ ฯลฯ”
ผม: สุดท้าย คุณอาจจะได้ตึกที่สวย แปลก เฉี่ยว แต่ใช้งานไม่ได้จริง
ผม: ตัวอย่างนี้มีให้เห็นตามเว็บไซต์ทั่วไปครับ
ผม: สวย แปลก ดูครั้งแรกแล้ว “ว้าว!” แต่ขอโทษนะครับ ไม่สามารถใช้งานได้จริงตามที่มันควรจะใช้งานได้
ผู้ถาม: ช่ายค่ะ
ผู้ถาม: พอเข้าใจและ
ผม: ขออนุญาตเอาการสนทนานี้ ไปลง blog และสอนหนังสือนะครับ เป็นตัวอย่างแนวคิดและทัศนคติหนึ่ง ที่พบเห็นได้ตามสังคมทั่วไป
ผู้ถาม: ขอบคุงค่ะ
ผู้ถาม: แป่ว
ผู้ถาม: ตามบาายคะ
ผู้ถาม: ก้อคิดไม่ออก
ผู้ถาม: เพราะยึดติดแต่สิ่งที่แตกต่างอ่ะคะ

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

A quick note about how to setup Aquamacs (Cocoa Emacs distribution) for coding Erlang (the next kid in town).

I assume you install Erlang via Macports so if you install it via any other mean, something will vary (I used to install it, along with everything else, from source; but currently the Macports is just easier).

The setup is simply adding the following lines into your ~/.emacs file

(setq load-path (cons "/opt/local/lib/erlang/lib/tools-2.6.4/emacs" load-path))
(setq erlang-root-dir "/opt/local/lib/erlang")
(setq exec-path (cons "/opt/local/lib/erlang/bin" exec-path))
(require 'erlang-start)

Please note that the actual path may vary from installation to installation (version numbers, most probably). So check yours.

ว่าจะไม่เขียนเรื่องนี้แล้ว แต่ว่าเขียนหน่อยก็ดี จากเด็ก ICT ที่ทำโปรเจคกับผมเอง ขอยก conversation มาทั้งหมดกันแล้ว

rp: ./configure: งานเป็นไงมั่งน้อง
IKE::: ก้อกำลังปั่นค่ะ
rp: ./configure: เหอๆ
IKE::: ได้ พี่คนหนึ่งช่วยสอน
rp: ./configure: ปั้นเหน่งป่ะ?
rp: ./configure: ใช่ @punneng ใน twitter หรือเปล่า
IKE::: ได้ข่าวว่ารู้จักกะอาจารย์ด้วย
IKE::: ช่ายคร๊าา
rp: ./configure: อ่อ
IKE::: พี่เค้าสอน แบบว่ายาวนานมาก
IKE::: วัน ละ 5hr ได้
IKE::: เอากาน แบบว่า รื้องานทำใหม่กานเลย
rp: ./configure: แล้วดีขึ้นมั้ย
IKE::: ไม่แงะcode เก่าแบบไม่เข้าใจ เร่ิมทำใหม่เลยน้อง ประมาณนั้น
IKE::: ดีขี้น มากมายอะคร่ะ
IKE::: เข้าใจ ตั้งแต่แรกเลย
rp: ./configure: ได้หมอนี่สอน ค่อยยังชั่วหน่อย
IKE::: รู้งี้ รู้จักพี่เค้า แต่แรกดีกว่า
rp: ./configure: เฮ้อ ก็พวกคุณมันเล่นไม่ทำความเข้าใจอะไรเลยนี่หว่า
IKE::: งานคงออกมาหรูกว่านี้เยอะ
rp: ./configure: ก็พวกคุณเล่นไม่พยายามทำความเข้าใจอะไรจริงๆ จังๆ นี่หว่า …. เล่นลอกโค้ดๆ แล้วก็มาพยายามแก้ๆ กันอย่างเดียว
IKE::: ช่ายๆๆ
IKE::: เปลี่ยนแนวคิดใหม่ด้วย
IKE::: พี่เค้า สอน ดีมากเลย สอน ให้คิดแบบที่ควรจะเป็น
rp: ./configure: ก็ดีแล้ว
rp: ./configure: ปัญหาของพวกคุณ (และเด็กทุกคนที่รู้จัก) คือ ไม่ทำความเข้าใจ ไม่พยายามทำความเข้าใจ และปฏิเสธที่จะทำความเข้าใจ ใน “แนวคิด” ใน “วิธีคิด” และใน “คอนเซปท์” ทุกคนพยายามลัดไปที่โค้ดหมด
rp: ./configure: ลอกโค้ด เอาโค้ด รันได้ แก้โน่นนี่ ปะๆๆ มันเข้าไป
rp: ./configure: อะไรแบบนั้น
rp: ./configure: ก็ดี ได้เริ่มคิดใหม่
IKE::: ค่ะ ยอมรับผิดแต่โดยดี
rp: ./configure: ดีกว่าไม่ได้เลย
IKE::: แต่พี่เค้าสอน ทุ่มเท มากอะค่ะ
IKE::: เดี๋ยววัน อาทิต นี้ ก้อ ไปให้เค้าสอน อีก
IKE::: พี่เค้าแบบว่า ไม่เน้น งานเสร็จ แต่ว่าเน้น เข้าใจในสิ่งที่ทำมากกว่า

อยากจะกราบขอบคุณ @punneng มากๆ เลย แต่คงไม่ได้เจอตัวจริงๆ กันซะที ก็เลยทำมันซะที่นี่น่ะแหละ แล้วก็อยากจะฝากสิ่งที่ผมคุยกับน้อง IKE ให้เป็นอุทาหรณ์กับน้องคนอื่นๆ ด้วยนะครับ

ว่า “อย่าลัดไปที่ coding” นะครับ มันไม่ค่อยจะช่วยอะไรคุณหรอก ถ้า paradigm ของความคิดมันเหมือนๆ เดิมที่คุณคุ้ยเคยมา ก็ดีไป แต่ว่าถ้ามันไม่ใช่แบบนั้น มันจะแย่เอาง่ายๆ และถ้ามันเป็นการแก้ไขง่ายๆ เล็กๆ น้อยๆ ก็อาจจะโอเค แต่ว่าถ้ามันเป็นเรื่องของการพัฒนาโปรแกรมขนาดใหญ่กว่านั้นขึ้นมาเมื่อไหร่เนี่ย ถ้าไม่กลับไปที่พื้นฐาน (back to basic) จะแย่เอาง่ายๆ เพราะว่ามันอาจจะทำให้อะไรหลายๆ อย่างแย่ในระยะยาวได้ง่ายๆ เลยทีเดียว

rp: ./configure: ปัญหาของพวกคุณ (และเด็กทุกคนที่รู้จัก) คือ ไม่ทำความเข้าใจ ไม่พยายามทำความเข้าใจ และปฏิเสธที่จะทำความเข้าใจ ใน “แนวคิด” ใน “วิธีคิด” และใน “คอนเซปท์” ทุกคนพยายามลัดไปที่โค้ดหมด
rp: ./configure: ลอกโค้ด เอาโค้ด รันได้ แก้โน่นนี่ ปะๆๆ มันเข้าไป

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

จริงๆ แล้วด้วยความสะดวกของเครื่องมือสมัยนี้ (ยกตัวอย่างเช่น bootstrapping method ต่างๆ ใน framework สมัยใหม่ ที่สร้างโครงของโปรแกรมพร้อมใช้งานให้เราเลย หรือว่าพวก migration tools และ version control ต่างๆ) มันช่วยให้เราทำงานขึ้น application ได้เร็วมากๆ อยู่แล้ว ดังนั้นเราควรใช้เวลากับการออกแบบดีไซน์ และคอนเซปท์มากขึ้นกว่าเดิม ไม่ว่าจะเป็นเรื่องของ entity relation ต่างๆ เรื่อง use cases ต่างๆ และเรื่องของ usability เป็นต้น และถึงเวลาที่จะต้องไปขึ้น application มันจะทำได้ง่ายและรวดเร็วมาก

สืบเนื่องเรื่องนี้นะครับ วิชา Object-Oriented Programming ที่ผมสอนเทอมนี้ ดู coding แล้ว “ห่วยบรม” ส่วนหนึ่งก็เพราะว่าผมยังไม่ได้สอนลง coding เลย ผมถือว่าผมจัดสอบส่วนของ Lab (ที่เป็น coding) เพื่อเก็บข้อมูลเบื้องต้นเท่านั้น ว่าพื้นๆ ฐานๆ ของน้องๆ ในเรื่องของการเขียน code (ที่ผมย้ำนักหนา .. ว่าเรียนคอนเซปท์ไปอย่างหนึ่งเนี่ย มันมากพอที่จะไปหัด coding เอง ซึ่งก็ดูเหมือนจะไม่ทำกันเลย) นั้นเป็นอย่างไรบ้าง

แต่ว่าเท่าที่ดูจากความเข้าใจ concept ก็ดูค่อนข้างจะดีพอสมควรแล้วล่ะครับ

ไปเจอมา เอามา note ไว้สำหรับตัวเองและเพื่อนๆ พี่ๆ น้องๆ ทุกท่านที่สนใจ Haskell เป็นหนังสือที่ดีพอสมควรเลยทีเดียว ละเอียด ตัวอย่างเยอะ ค่อนข้างเป็นปัจจุบันมากๆ และมีประโยชน์กับ Real World จริงๆ (บ้างล่ะน่า) ไม่ใช่แบบหนังสือ Functional Programming ทั่วไปที่ยกว่า FP ดีอย่างนั้นอย่างนี้ แต่ว่าไม่ค่อยจะมีตัวอย่าง Real World ที่มัน convincing เท่าไหร่เลย ยกแต่ประโยชน์ที่ … ขอโทษนะ ต้องบอกว่า “ถ้าไม่ได้เขียน FP เป็นอยู่แล้ว ก็คงจะไม่ซึ้งกับมันเท่าไหร่ ว่ามันเจ๋งแค่ไหน” มากกว่า

แปะลิงค์ก่อน

Real World Haskell (beta) by Bryan O’Sullivan, Don Stewart, and John Goerzen

Haskell เป็นภาษาโปรแกรมที่ผมชอบมากที่สุดภาษาหนึ่งเลยก็ว่าได้ นอกจากนี้ยังเป็นสิ่งแรกในโลกที่สอนให้ผมรู้จักและเข้าใจความรู้สึกของคำว่า “รักแรกพบ” ด้วย

เรื่องของเรื่องมันมีอยู่ว่า วันนั้นนั่งเขียนโปรแกรมอะไรซักอย่างอยู่ในห้องคอมพิวเตอร์ที่มหาวิทยาลัย Tsukuba (ไม่ได้เขียนอะไรใหญ่โตหรอก รู้สึกจะหัดเขียนพวก data structures เล่นอยู่) แล้วเพื่อนสนิทมากที่สุดคนหนึ่ง ชื่อ Nao Hirokawa (จริงๆ แล้วเป็นรุ่นพี่) ก็เดินเข้ามา แล้วก็ชวนคุยเล่นกันโน่นนี่ พอเห็นที่เราเขียนเล่นอยู่ ก็ถามว่า “เฮ้ ทำไมไม่ใช้ Haskell?” เราก็เลยถามว่า มันคืออะไรหว่า Hirokawa ก็เลยถามว่า รู้จัก Quick Sort มั้ย แหม ใครจะไม่รู้จัก เค้าก็เขียน Quick Sort เป็น Haskell ให้ดู พร้อมกับที่เราอ้าปากค้างตาโต (โดนแหก — จริงๆ แล้วรู้สึกว่า Quick Sort นี่เป็นตัวอย่างตลาดของ Haskell เลยนะ .. คงไม่มีใครไม่ยกตัวอย่างอันนี้มาแหกตาชาวบ้านเวลาโชว์ Haskell) แล้วก็เล่น List Comprehension ให้ดูอีกนิดๆ หน่อยๆ

นั่นแหละ รักแรกพบครั้งแรกในชีวิต

จาก ข้อความของ @sugree ใน twitter

my profession is coding. don’t hire me to be manager. it’s useless.

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

และท่านก็ต่ออีกว่า

เราก็เอาโปรแกรมเมอร์ที่เก่งๆ (มักจะเป็นคนที่เก่งที่สุด) ไปโปรโมทเป็นผู้จัดการ ส่วนมากผลที่ได้ก็คือ เสียโปรแกรมเมอร์เก่งๆ ไปคนนึง แล้วก็ได้ผู้จัดการห่วยๆ มาคนนึงแทน

KID In Digital ก็เรียนรู้เรื่องนี้แบบ Hard-way ล่ะนะ แต่ตอนนี้น้ององ(คช) คนที่ลองทำงานเป็น Project manager อยู่ครึ่งปี ก็อยากจะกลับมาเขียน code แล้ว แต่ใครจะมาเป็น Project manager แทนล่ะ? เพราะว่าผมเองก็อยากจะกลับไปเขียน code เหมือนกัน……

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

บางทีถ้าไม่ลองจับให้มีบทบาทบางอย่าง เราจะรู้ได้ยังไงว่าใครเหมาะ/ไม่เหมาะกับอะไรบ้าง ก็ต้องให้โอกาสกันเรียนรู้บ้าง

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

Note for myself:

• Next time my developers say “X months” for developing any project, I will say “2X months” to the customers. So my developers will have time to talk to each other more and spending time developing relationship through playing games and doing all other activities with each other.
• Next time my developers say “X weeks”, I will say “X weeks + 2X days”. My developers love to think of weekend and holidays as ‘working days’ which is simply wrong and give no breathing window if anything goes wrong.
• I will train all the newcomers myself, like I once did to my current team of developers. Never again asking any of my developers doing it.
• I have to beg my developers to remember: The opposite of playing isn’t working. It’s depression.
• Never let any developer working alone again.
• Don’t promote my top developer to do management work. Myself included. Why? I still believe I’m one of the finest developer in my office, and if I’m doing project management work; my team looses one good developer and get one bad manager.
• Be more sensitive to small personal details. It ruins things.

อ่านจาก OSnews เรื่องข่าว 1.6 LiveCD ไม่ทันไรก็มีข่าว 1.8 LiveCD อีก

รู้สึกว่าช่วงนี้จะ active มากหน่อยนะเนี่ย …. เคยชอบมากเลย project นี้ แต่ว่าพอเปลี่ยนจาก Linux มาเป็น OS X แล้วก็ไม่ค่อยได้เล่นเท่าไหร่ รู้สึกว่าครั้งสุดท้ายที่ลองเล่นนี่ชาตินึงแล้วมากๆ

รู้สึกดีจัง กับ project ที่เราเคยชอบมากๆ … แต่ว่าด้วยอะไรหลายๆ อย่างทำให้ต้องเลิกเล่นไป แล้้วก็ไม่ได้ contribute อะไรเลย (แม้แต่ code ซักบรรทัด — เคยคิดว่าจะทำ app ไปลง GNUstep เหมือนกัน …​แต่ว่าไม่ล่ะ ตอนนี้อยากลองเขียนลง iPhone มากกว่า)

วันนี้กลับออฟฟิชเมื่อไหร่ จะลองเล่นดูครับ

หมายเหตุ

• บทความนี้เขียนครั้งแรกใน blog วิชา 517211 Programming Languages และเอามาลงใหม่ที่นี่อีกที
• บทความนี้เกี่ยวข้องกับ Standard Library Headers ของ C/C++ เท่านั้น ไม่เกี่ยวข้องกับ Non-standard Library (เช่น conio.h หรือว่า library อื่นๆ ที่ download มาใช้เอง เช่นพวก image processing หรือว่า XML แต่อย่างใด)

ใน C++ (ตั้งแต่ C++98) เนี่ย header มันเปลี่ยนจาก .h เป็นไม่มี .h แทน เช่น iostream.h ก็เป็น iostream นอกจากนี้แล้วยังมีอีกเรื่อง คือ headers ทั้งหลายที่มาจาก C ซึ่งเปลี่ยนจาก .h เป็นใช้ c นำหน้า เช่น stdio.h เป็น cstdio แทน

โดยทุกอย่างที่อยู่ใน C++ standard library นี้จะอยู่ใน namespace ที่ชื่อ std ซึ่ง namespace ก็คือ ที่สำหรับเก็บชื่อ ว่่าชื่อนี้เป็นของอะไร เช่น std::cin คือ cin ที่อยู่ใน std เป็นต้น

ทีนี้ก็เลยกลายเป็นสาเหตุเล็กๆ น้อยๆ ที่เราควรจะสนใจและใช้ header ให้มันถูกต้องเสียที เวลาที่เขียน C++

• ความเก่าและใหม่ เพราะว่า C++ บาง implementation ยังคงเก็บ .h headers ไว้เพื่อให้ compatible กับ code เก่าเท่านั้น (คือให้ code เก่าที่เคยเขียนมาสมัย pre-standard ยังคง compile ได้เท่านั้น) จะไม่มีการ update ให้ใช้ความสามารถใหม่ๆ ได้แต่อย่างใด

  ลองคิดว่าเป็นอารมณ์เดียวกับที่ Microsoft เลิก update Windows 98 ไปนานแล้ว …. แต่ว่าคุณยังเก็บ Win98 อยู่ เพราะว่ายังมีบางโปรแกรมที่ยังคงใช้มันอยู่ และใช้บน XP ไม่ได้น่ะแหละ

• namespace พูดเป็นเล่นครับ นี่เรื่องใหญ่กว่าที่หลายๆ คนคิด ใครที่เคยเขียน C/C++ จะเข้าใจดี เรื่องความซ้ำกันของชื่อฟังค์ชัน หรือว่าชื่อ constant ต่างๆ เป็นปัญหาหลัก เนื่องจากว่ามันมีซ้ำไม่ได้เด็ดขาด (ห้ามประกาศซ้ำ ในหนึ่งโปรแกรม) สมมติว่าผมใช้ library บางตัว และมี function ที่ชื่อซ้ำกับ standard library หรือว่าซ้ำกันเองระหว่าง library อื่นๆ นี่จบกันเลย ต้องแก้โน่นแก้นี่เยอะมาก

  ทีนี้เป็นเรื่องครับ เพราะว่า standard library ของ C++ นั้นค่อนข้างจะใหญ่พอควร และมีชื่อที่ค่อนข้างโหลอยู่มากมาย เช่น vector (ใน header ชื่อ vector) หรือว่า max, find, count (ใน algorithm) เป็นต้น การที่พวกนี้อยู่ใน namespace std จะช่วยป้องกันปัญหาชื่อซ้ำกันได้บ้าง (เยอะเลยแหละ) เพราะว่าปกติชื่อมันจะไม่ซ้ำกันข้าม namespace

  ปัญหานี้มันก็อารมณ์เดียวกับคนชื่อซ้ำๆ กันในคณะ (เช่น ชื่อ ฝน หรือว่า เมย์ … ชื่ออะไรดีที่มีเยอะๆ?) แต่ว่าถ้าบอกว่า ฝน เอกคอมพ์ นี่คงจะน้อยลงไปเยอะเลย (โอกาสซ้ำกันก็ยังพอมีอยู่ แต่ว่าสำหรับ std namespace แล้วการันตีว่าไม่มีการซ้ำภายใน namespace เดียวกัน) .. งั้นการบอกว่า std::max ก็เหมือนกับบอกว่า เอกคอมพ์::ฝน น่ะแหละ … แต่ว่าถ้าชื่อไม่ค่อยจะโหล เช่น เอิง อะไรแบบนี้ก็แล้วไป (ถ้าเป็น C++ ก็คงจะพวก bind2nd อะไรทำนองล่ะมั้ง)

• เรื่องความเข้ากันได้ของ C และ C++ เอง …. เรื่องนี้ไม่น่ามีล่ะครับ แต่ว่าก็ว่าไม่ได้ เพราะว่าไม่มีใครกำหนดไว้ชัดเจน แต่ว่าเนื่องจาก C และ C++ เอง นับวันก็ยิ่งจะแตกต่างกันในเรื่องของรายละเอียดเล็กๆ น้อยๆ มากขึ้นๆ เรื่อยๆ ถ้าเราใช้ .h library เมื่อไหร่ นั่นหมายถึงเราอาจจะใช้ library ของ C อย่างไม่รู้ตัวครับ นั่นแปลว่า ถึงเราจะแม่น devils in details ของ C++ มากแค่ไหน แต่ว่าถ้าเราใช้ของ C โดยที่เราคิดว่าใช้ของ C++ อยู่ล่ะ? ….. เราจะเจอปัญหาเล็กน้อยพอควรทีเดียว และเราจะไม่คิดด้วย ว่ามันเป็นปัญหาที่จุดนี้

  เรียกว่าถ้าเราจะใช้ C ก็ใช้ .h ให้ชัดเจน แต่ว่าถ้าจะใช้ C++ ก็เอา .h ออก และใช้ c ขึ้นหน้า (เช่น cstdio, cstdlib, cstring, cctype เป็นต้น)

  อ่อ ….​ และถึงตรงนี้เลยฝากไว้นิดเลยละกัน ว่า string.h ของ C (ที่มีพวก strlen) มันจะกลายเป็น cstring ใน C++ นะครับ ถ้า string ของ C++ จะเป็นอีกตัวนึง ซึ่งเป็นคนละเรื่องกันเลย

คงเป็นความรู้ประกอบการตัดสินใจในการเลือกใช้ header สำหรับการเขียน C/C++ ได้บ้างครับ

Ruby > Ruby 1.9.0 is released ของขวัญ Christmas จาก Matz!

รอคอยกันมานาน กับ Ruby 1.9 ซึ่งเป็น major release แรกหลังจาก 1.8 ออกมานานแล้ว ซึ่งใน version นี้จะมีอะไรหลายๆ อย่างเพิ่มเข้ามา โดยเฉพาะที่หลายๆ คนรอคอยกัน ก็คือประสิทธิภาพที่เพิ่มขึ้น ความเร็วที่เพิ่มขึ้น

• เนื่องจากมันเป็น development release ดังนั้นมันจะยังไม่ stable นะครับ (จาก message ของ Matz เองใน ruby-forum.com
  

  We couldn’t make it error free, but it’s fairly good, we hope.

• ใครที่ใช้ Ruby on Rails เป็นหลัก อย่าเพิ่ง ลงเด็ดขาดครับ เพราะว่ามันยังไม่ compatible กัน ทาง Rails จะยังต้องเปลี่ยนโน่นเปลี่ยนนี่เยอะเหมือนกันนะ (อันนี้ผมไม่ confirm ครับ เพราะว่าผมยังไม่ได้ลองดู Ruby 1.9 และภายในของ Rails ละเอียดพอที่จะให้ comment อะไรได้) แต่ว่าก็มีคนศึกษาเรื่องนี้เหมือนกัน เช่นที่ eigenclass เป็นต้น
• ในขณะที่ประสิทธิภาพสูงขึ้นพอควรจาก benchmark ต่างๆ นั้น … ประสิทธิภาพกับ Rails (เท่าที่ test ได้) กลับไม่ดีขึ้นเท่าที่ควร (และแย่ลงด้วยในบางกรณี)

ร้องเพลงรอกันไปนิดดีกว่าครับ แต่ว่าถ้าใครมีเวลาก็ลองเล่นดูก็ดีครับ เพราะว่าไม่ช้าก็เร็ว เราก็ต้องเจอกับมันอยู่แล้ว