Blog

 

ลักษณะการทำงานเป็นทีม

by

คำถาม ทีมเราได้ทำการไปแข่งคอมพิวเตอร์ สมาชิกในทีมมี 3 คน … แต่ computer เครื่องเดียว .. โดยให้เวลา 5 ชั่วโมง ซึ่งมีปัญหาอยู่ 8 ข้อ ควรจะทำยังไงดี?

ส่วนใหญ่จะคิดว่า

1) แบ่งกันทำคนละข้อ หรือไม่ก็ 2) สุมหัวกันคิดให้หมดทุกข้อ

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

ซึ่งมันไม่มีจริงหรอก เอางี้นะ ปกติเรามีสามคนใช่มั้ย? เราทำแบบนี้

1) คนที่มองปัญหาเก่งที่สุด รู้ algorithm มากที่สุด แม่น data structure มากที่สุด จะเป็นคนนั่งอ่านปัญหา วิเคราะห์ปัญหา … จากนั้นเมื่อได้แล้ว จะเรียกคนที่สอง มาทำงานต่อ

2) คนที่สอง ก็คือ คนที่แม่น library ที่สุด แม่น feature ต่างๆ ใน programming language ที่ใช้ที่สุด เมื่อฟังจากคนแรก แล้วก็จะนั่ง implement idea, algorithm, data นั้นลง และเนื่องจากมี com เครื่องเดียว ดังนั้นการ debug จึงต้องทำ “นอกจอ” เพื่อไม่ให้เสียเวลา

3) คนที่สาม คือ debugger ที่จะเอามาจากการ printout และมาทำการ core dump เพื่อมานั่งวิเคราะห์

ซึ่งถ้า “แบ่งๆ กัน -> สุดท้ายนะ มันแก้ได้แต่ข้อง่ายๆ พอข้อยากๆ จะตายหมด เพราะว่า บางคน คิดออก แต่ว่าไม่รู้ feature ของภาษาที่ใช้มากพอ พอเอามา debug ก็ ช่วยกันไม่ได้ เพราะว่าแต่ละคนเขียนต่างกัน”

หรืออย่าง “สุมหัวกันทำ -> ทะเลาะกันก่อนจะได้ลงมือเขียน แย่ง keyboard กัน แล้วมาทะเลาะกันตอน debug ฯลฯ มันไม่ใช่ team work”

มันแค่ทำงาน “ด้วยกัน” ไม่ใช่ทำงาน “ร่วมกัน”

ตัวอย่าง

นาย A จะอ่านปัญหา ทำการวิเคราะห์ และจะมาอธิบายให้ นาย B ฟัง และนาย C จะฟังด้วย เพื่อให้รับรู้ algorithm

จากนั้น นาย B จะไปพิมพ์ implement ให้เร็วที่สุด ให้ได้ working program ที่คิดว่าเร็วที่สุดเท่าที่จะเร็วได้ เพราะว่าในตอนนี้ นาย B เป็นคนเดียวที่จำ standard c++ ได้มากที่สุด ใช้ stl ได้ทั้งหมดโดยไม่ต้องเปิดอะไรเลย

นาย C จะมานั่งดูด้วย เพื่อให้เห็นวิธีที่นาย B เขียนอะไรบ้าง จากนั้น compile, run test .. แน่นอนว่าไม่ work ก็จะจะทำการ print เอา source code และ memory core dump จาก printer ส่วนกลางออกมา

นาย C จะมานั่ง debug ไล่ core จากนั้น นาย B ก็จะไปฟังการวิเคราะห์ปัญหาข้อใหม่จาก นาย A ซึ่งจะสามารถวิเคราะห์ปัญหาได้อย่างอิสระ ไม่ต้องยุ่งกับเรื่อง implementation และอาจจะช่วย debug บ้างนิดหน่อย

นาย B ไม่ต้องคิดมากเรื่องการแก้ปัญหา หรือว่า debug เท่าไหร่

นาย C ไม่ต้องคิดแก้โจทย์ แต่ว่าต้องแก้ปัญหาในโปรแกรมที่ นาย B เขียน

แบบนี้สิ คือการทำงานเป็นทีม

ซึ่งการแบ่งโจทย์ไปคิดคนละข้อ หรือการสุ่มหัวกันคิด –> นี่เค้าเรียกการแบ่งหน้าที่ด้วยเหรอ จริงไหม

ดังนั้น … “แบ่งโจทย์ไปคิดคนละข้อ หรือการสุ่มหัวกันคิด ..” มันไม่ใช่ “แบ่งหน้าที่”

หน้าที่ของ programmer คืออะไร
1) วิเคราะห์ปัญหา
2) เขียนโปรแกรม
3) แก้โปรแกรม

…….. มันควรจะเป็นแบบนี้

 

หยุดและคิด

by

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

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

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

มีอาหารหลากชนิดมากขึ้น แต่ไม่มีคุณค่าทางอาหาร
ยังมีช่วงเวลาที่คนแต่งงานกันมากขึ้น แต่ก็มีการหย่าร้างกันมากขึ้น
มีบ้านที่สวยงาม แต่ก็มีบ้านแตกสาแหรกขาด

“แต่จงยอมรับไว้ว่า บางสิ่งที่ดีเกิดขึ้นกับผู้ที่มองโลกในแง่ดีเสมอ”

 

เลือกอะไรระหว่าง แต่งงาน หรือคอมพิวเตอร์

by

เหตุผลที่ทำให้การเล่นคอมพิวเตอร์ดีกว่าการแต่งงาน

  1. ถ้าคุณไม่อยากยุ่งกะมัน คุณก็ปิดมันได้
  2. มันไม่มีทางบอกคุณว่า “คืนนี้อย่า Login เลย ฉันปวดหัว”
  3. คุณบอกมันได้ทุกอย่าง และแน่นอน มันจะไม่ไปบอกใครต่อ
  4. แถมคุณยังสั่งให้มันบอกคุณ ในสิ่งที่คุณอยากได้ยินด้วยนะ
  5. มันไม่โวยวายอะไร ถึงแม้ว่าคุณจะกลับบ้านตอนตี 3 พร้อมลอยลิปสติกบนแก้ม
  6. มันแย่งที่นอนคุณไม่ได้ รวมถึงผ้าห่มคุณด้วย
  7. คุณไม่ต้องทำอาหารให้มันกิน (แต่มันอาจจะกินค่าไฟแทน แค่สองหลอดเท่านั้น)
  8. มันจะจำในสิ่งที่คุณอยากให้มันจำ และลืมในสิ่งที่คุณอยากให้ลืม
  9. มันไม่รุ้จักเหนื่อย ไม่ว่าคุณจะใช้งานมันหนักแค่ไหนก็ตาม (ยกเว้น จะแฮงค์ไปซะก่อน)
  10. แถมมันยังไม่เคยบ่น แม้ว่าคุณจะไม่เคยพามันไปเที่ยวที่ไหนด้วยนะ

เหตุผลที่ทำให้การแต่งงานดีกว่าเล่นคอมพิวเตอร์
หมายเหตุ:แก๊กนี้ ผู้ปกครองควรพิจารณาก่อนให้บุตรหลานอ่าน

  1. เวลาคุณจะใช้งาน คุณไม่ต้องใช้ password (โดยเฉพาะเวลาคุณภรรยาใช้คุณสามี ส่วนเวลาคุณสามีจะใช้ ก็อาจจะต้องใส่ password เช่นว่า “ที่รักจ๊ะ …” เป็นต้น)
  2. เวลาไฟดับ คุณยัง “ทำอะไร ๆ” ต่อไปได้ เพราะเรื่องแบบนี้ ทำมืด ๆ ดีกว่า
  3. อืม… คุณใช้คอมพิวเตอร์ต่างหมอนกอดไม่ได้ะ แม้จะเป็น Notebook ก็ตาม
  4. อืม… คุณเอาหัวซบบน keyboard แทนหน้าตักภรรยา ไม่ได้หรอก มันไม่สบาย และไม่โรแมนติกด้วย
  5. เวลาคุณพิมพ์คำสั่งผิด คอมพิวเตอร์ก็จะโวยวายทันที แต่ถ้าคุณใช้คำผิด ก็คงไม่มีใครว่าอะไรหรอก (ยกเว้น ภรรยาหรือสามีของคุณ เป็นครูสอนภาษาไทย)
  6. เวลาคุณเล่าเรื่องขำขันที่คุณคิดว่ามันตลกที่สุดในโลก ให้คอมพิวเตอร์ฟัง มันไม่หัวเราะหรอก
  7. อืมมม ต่อให้เครื่องคุณเป็น PIII-800 ผมก็คิดว่า คุณพามัน(หรือมันพาคุณ)ไปดูหนังไม่ได้หรอกนะ
  8. ถึงแม้ว่าคอมพิวเตอร์คุณจะไม่บ่นเวลาคุณเมากลับบ้านตอนตี 3 แต่เชื่อเถอะ มันไม่เก็บอ้วกให้คุณหรอก ถึงแม้คุณจะอ้วกบน keyboard ก็ตามที
  9. อืม… คุณอาจจะรักคอมพิวเตอร์คุณจนสุดหัวใจ แต่เชื่อผมเถอะ มันไม่รักคุณหรอก
  10. สุดท้าย ต่อให้คอมพิวเตอร์สวยน่ารักแค่ไหน (เช่น เครื่องไอแมค) คุณทำเรื่อง”อย่างว่า” กับคอมพิวเตอร์ไม่ได้หรอก (ถ้าคิดจะทำ ควรปรึกษาแพทย์หรือเภสัชกรก่อนทุกครั้ง) ปรึกษา “จิตแพทย์” ท่าจะ work กว่ามั้ง

เหตุผลที่ทำให้การแต่งงานพร้อมกันการเล่นคอมพิวเตอร์ดีที่สุด

  1. เวลาคุณต้องไปไหนไกล ๆ ก็สามารถคุยกันผ่าน IRC ได้ไง จะโทรศัพท์มันก็แพงออก
  2. เวลาคุณไม่ค่อยได้เจอกัน ฝาก Note ไว้ที่คอมพิวเตอร์ เช่นเขียนไว้ที่ Wall Paper ว่า “คิดถึงจัง
  3. คืนนี้เจอกันนะ ที่รัก…” ถ้าเขาเห็นแล้วไม่อมยิ้มก็แปลกแล้ว
  4. การได้หนุนตักภรรยา เล่นคอมพิวเตอร์ มันอาจจะไม่สบาย(มาก ๆ ) แต่มันก็โรแมนติกน่าดูนะ
  5. วันเสาร์อาทิตย์คุณก็เกี่ยวก้อยกันไปเดินซื้อของที่พันธุ์ทิพย์ได้ สนุกกว่าไปคนเดียวตั้งเยอะ(อิจฉา อิจฉา)
  6. หรือไม่ก็ ถ้าเขาเล่นโปรแกรมอะไรไม่เป็น ก็ถือโอกาศสอนซะเลย จะได้มีอะไรทำด้วยกันไง
  7. เวลาคุณมีลูก คุณก็สามารถสร้างความสัมพันธ์กะลูกด้วยการสอนคอมพิวเตอร์ให้ลูกก็ได้นะ
  8. คอมพิวเตอร์เนี้ย มันต้องนั่งตรงหน้า ดังนั้นเวลาจะใช้คอมพิวเตอร์ด้วยกัน มันก็ต้องนั่งเบียด ๆ กัน หรือไม่ก็เก้าอี้เดียวกันไปเลย มันไม่สบายแต่อบอุ่นดีออก(แต่จะลงท้ายด้วยการทำอย่างอื่นหรือเปล่า ก็แล้วแต่ละครับ)
  9. ถ้าทะเลาะกัน เค้าไม่ยอมพูดด้วย ก็ใช้คอมพิวเตอร์ง้อ ก็ได้ (แต่อันนี้ก็แล้วแต่ความสามารถนะครับ) และถ้าคุณทนคิดถึงกันไม่ไหว ก็หอบงานมาทำที่บ้าน ต่อ modem ก็เหมือนอยู่ที่ office แล้วละ
  10. ผมก็เชื่อว่า หลาย ๆ คู่ ก็คงได้แต่งงานกันก็เพราะ Computer/Internet นี้แหละ จริงมั้ยครับ :)

 

ขอบเขตของตัวแปรในภาษา C++ (Scope of variables In C++)

by

ตัวแปรทั้งหมดที่เราทำการประกาศค่าไว้ก่อนแล้ว นั้นในภาษา C++ การประกาศค่าตัวแปรจะทำที่ใดของ source code ก็ได้ และระหว่างการประกาศตัวแปรนั้น แต่ละขอบเขตของฟังค์ชัน ( Scope of Function ) นั้นถึงแม้จะชื่อเหมือนกัน แต่ว่าก็ไม่ได้หมายความว่าจะเป็นตัวแปรจะค่าเหมือนกันแต่อย่างใด ซึ่ง ตัวแปร A ที่อยู่ใน ฟังค์ชัน X จะไม่เท่ากับค่าของตัวแปร A ที่อยู่ในฟังค์ชัน Y แต่อย่างใด เพราะว่าอยู่กันคนละขอบเขตกันเราเรียกตัวแปรในขอบเขตแบบนี้ว่า ตัวแปรเฉพาะที่ (ในบทความนี้ขอพูดทับศัพท์ไปเลย เพื่อให้เข้าใจง่ายว่า Local Variables) ซึ่งจะมีค่าและสามารถใช้งานได้เฉพาะฟังค์ชัน ที่มันเกิดร่วมด้วยเท่านั้น

ตัวอย่าง 1

int X () {

   int A = 5;

   return A;

}

int Y () {

   int A = 10;

   return A;

}

int main() {

   std::cout < < X()<< ”;

   std::cout << Y()<< ”;

   return 0;

}

ผล

5 10

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

ตัวอย่าง 2

int x = 5; // Global Variable

int main() {

   double y = 3.1415; // Local Variable

   std::cout < < y << ”; std::cout << x << ”; return 0;

}

ผล

3.1415 5

แต่ ……

มันยังมีข้อที่เรามองข้ามไปคือ ถ้าเราประกาศตัวแปร เหมือนกับ Global Variable แล้วนั้น จะทำให้ตัว Compiler มองว่าตัวที่ประกาศอยู่ในฟังค์ชันคือตัวแปรที่มีความสำคัญหรือ ศักดิ์มากกว่า

ตัวอย่าง 3

int x = 5;

int main() {

   double x = 3.1415; /* ทำการซ่อน Global Variable x = 5 ไว้ */

   std::cout < < x << ”; /* แสดงตัวค่าตัวแปร Local Variable แทน */

   std::cout << ::x << ”;

   /* ใช้ Scope resolution operator มาวางให้ข้างหน้าตัวแปร

   เพื่อบ่งบอกว่าเราต้องการใช้ตัวแปร Globale Variable

   แทน Local Variable*/

   return 0;

}

ผล

3.1415 5

จากตัวอย่างจะเห็นว่าเราจะทำการประกาศตัวแปรทับซ้อนกันก็ได้ได้แต่ว่าไม่เป็นผลดีและอาจเกิดการสับสนใจการใช้งานได้ ทำให้ส่วนใหญ่แล้วจะใช้ Local Variable กันเยอะมาก เพราะว่าจัดการได้ง่าย แต่ก็มีในหลายๆ กรณีเช่นกันที่ต้องใช้ อย่างเช่นตัวแปรที่ต้องการแชร์ค่าเริ่มต้นการทำงานเช่นค่าของ Percen (100) หรือ ค่าของ Pi (3.1415) เป็นต้น เพราะเป็นค่าที่ไม่มีการเปลี่ยนแปลงไม่ว่ากรณีใดๆ

Note !

คุณสามารถที่จะบอก Compiler ว่าคุณต้องการใช้ Global Variables แทนการใช้ Local Variable ได้เมื่อคุณตั้งชื่อ Variable ภายใน Function นั้นเหมือนกับ Global Variable โดยใช้ :: (The Scope Resolution Operator) ไว้ด้านหน้าตัวแปรนั้นๆ …

:: identifier

class-name :: identifier

namespace :: identifier

ซึ่งการอ้างถึงของ :: (The Scope Resolution Operator) นั้นสามารถอ้างได้ตั้งแต่ variable, class และnamespace ได้ด้วย

ซึ่งจาก "ตัวอย่างที่ 3" ถ้าคุณมี Nested Local Scopes (มี Scope ตัวแปรซ้ำซ้อนกับ Global Variable ) ตัว Compiler จะไปเอาค่าหรืออ้างอิงตัวแปรที่อยู่ใน Function ก่อนเสมอ ถ้าจะใช้ Global Variable ก็เพียงทำหลักการของ The Scope Resolution Operator นั้นเอง

จากที่เราได้รู้แล้วว่า คำว่า Global Variables นั้นสามารถที่จะอ้างอิงได้จากทุกๆ ที่ใน code หรือใน ฟังค์ชัน ซึ่งจะคงอยู่ตลอดหลังจากการตั้งตัวแปรนั้นๆ ขึ้นมาใช้งานแล้ว แต่คำว่าตัวแปรเฉพาะที่ Local Variables นั้นตัวแปรจะถูกจำกัดอยู่ในขอบเขตที่ตัวเองได้เกิดขึ้น แต่ถ้าคุณสร้างมันในตอนแรกของฟังค์ชัน (ในที่นี่หมายถึง main ฟังค์ชันของ C++) ตัวแปรนั้นๆ จะอยู่ใน main ฟังค์ชันเท่านั้น และจะไม่ไปยุ่งกับตัวแปรอื่นๆ ในฟังค์ชันอื่นๆ ด้วยถึงแม้ชื่อจะเหมือนกันในฟังค์ชันอื่นๆ ก็ตามที

ใน C++ นั้น ขอบเขต ของ Local Variables นั้นจะอยู่ที่ ( brackets { } signs ) นั้นเอง ซึ่งถ้าคุณตั้งมันในขอบเขตดังกล่าวแล้ว ตัวแปรจะไม่ยุ่งเกี่ยวกับภายนอกฟังค์ชันแน่นอน

ตัวอย่าง 4

int main(){

   for (int i = 0; i < 100; ++i) {

      int x = 42;

      if (x < i) {

         double x = 3.14; std::cout << x; // Output ที่จะ Print ออกมาจากหน้าจอคือ 3.14

      }

      std::cout << x; // Output ที่จะ Print ออกมาจากหน้าจอคือ 42

      } // ส่วนนี้จะ Error เพราะว่าเราไม่ได้ตั้งตัวแปรไว้ในขอบเขตนี้ ด้วยเหตุผลได้กล่าวไปแล้วในข้างต้น

   std::cout << x;

   return 0;

}

จากเนื่อหาด้านบนคงทำให้หลายๆ คนเห็นภาพมากขึ้นในเรื่องของขอบเขตของตัวแปรในภาษา C++ นะครับ

อ้างอิงจากหนังสือ C++ in a Nutshell ของ O’Reilly


 

เรียนโปรแกรมมิ่ง หรือ Computer Science จงเป็นเจ้านายภาษา …

by

ขอท้าวความนิดนึง ว่าทำไมผมถึงเขียนแบบนี้

คืออันนี้ผมไป ได้มาจากพี่เดฟ (ithilien_rp) post ตอบไว้ใน pantip.com โดยที่เจ้าของกระทู้เขียนว่า ในlonghorn นั้น microsoft จะใช้ภาษาใหม่ ซึ่งก็คือ mc++ ดังนั้นขอให้พวกโปรแกรมเมอร์ทั้งหลายระงับการเรียนโปรแกรมกันไว้ก่อนเพราะว่าอีกไม่นานต้องเปลี่ยนอีก

อะไรทำนองนี้แหละครับ เนื้อหาบทความีดังนี้ครับ

         การเรียนรู้ platform/library/language ใหม่ๆ เป็นเรื่องปกติของ programmer อยู่แล้ว ดังนั้นผมว่ามีของใหม่มา ก็ไม่ใช่เรื่องแปลกอะไร

         การเรียนรู้อะไรผมไม่อยากให้ดูที่เปลือกนอกมากไปนักน่ะครับ อย่าไปดูที่ syntax, libraryอะไรให้มากนัก ดูที่แนวความคิด หรือว่าปรัชญาของการเขียนโปรแกรมจะดีกว่ารวมไปถึง algorithm flow หรือว่า program design ด้วย เพราะว่า ถึงแม้ภาษาต่างๆ มันจะเปลี่ยนไป หรือว่า library/framework ต่างๆ มันเปลี่ยนไปตามกาลเวลาของมัน ไอ้พวก algorithm หรือว่า design philosophyพวกนี้ไม่ค่อยเปลี่ยนตามหรอกครับ หรือว่าเปลี่ยนตามก็ช้ากว่าไม่รู้กี่เท่า

         เรียนprogramming language ใหม่ๆ ภาษานึงนี่ ผมว่ามันไม่ใช่เรื่อง big dealอะไรเลย ตอนที่ผมเปลี่ยนมาใช้ mac os x ใหม่ๆ แล้วอยากจะเขียนโปรแกรมบน osx ผมก็ต้องเรียน objective-c ซึ่งผมไม่เคยเห็นมาก่อนในชีวิตก็ไม่มีอะไรมาก ใช้เวลาครึ่งวันอ่าน syntax, keyword ใหม่ๆ ว่ามีอะไรบ้างอีกครึ่งวันหาพวก FAQ ว่ามันมีอะไรต่างจาก c/c++/java มั่งวันที่สองวันที่สาม ก็เขียนอะไรใน objective-c ได้แล้วส่วนเรื่องการเขียนโปรแกรมใน os x นี่ แน่นอนว่า architecture มันต่างจากwindows โดยสิ้นเชิง ดังนั้นความรู้อะไรก็ตามที่ผมรู้มาจาก win32, mfc,.net ใช้ไม่ได้เลย (ของตาย ยกเว้น M$ จะ port ไปลง แต่ว่า .net ก็มีdotGNU ก็พอจะใช้กันได้บ้าง) แต่ว่าก็เรียนรู้ Cocoa framework (ที่เป็นnative framework ของ mac os x) ก็ใช้เวลาไม่นานเท่าไหร่ ก็เขียน GUIapplication ได้แล้ว ใช้ system service ได้พอสมควร (ก็อ่านๆ พวก basicแล้วที่เหลือก็เปิด reference เอา)

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

1. แยกการเรียน “ภาษา” กับการเรียน “library/framework” ออกจากกัน
         เดี๋ยวนี้library/framework ใหม่ๆ ส่วนมากจะ support หลายภาษา และ codeที่เขียนเรียกใช้ library เหล่านั้นในแต่ละภาษาจะไม่ต่างกันมากเท่าไหร่(ลองดู code ที่ใช้ .NET framework ที่เขียนใน VB.NET, C#.NET หรือว่าManaged C++.NET สิครับ ออกมาแทบจะเหมือนกันเลย ผมอ่านหนังสือ VB.NET นี่แปลง code เป็น C# ได้แบบแทบไม่ต้องคิดเลย เกือบจะบรรทัดต่อบรรทัด แปลงแค่syntax กับ keyword แล้วก็ structure นิดหน่อย)
         ดังนั้นการแยกการเรียนรู้ library/framework ออกจากการเรียนภาษาเป็นเรื่องที่สำคัญครับ ตามความคิดของผม

2. อย่าไป focus กับภาษามากเกินไป ดูที่ algorithm + program design มากๆ
         ภาษาก็เป็นแค่เครื่องมือแม้ว่าภาษาแต่ละภาษาจะมีข้อดีข้อเสียไม่เหมือนกัน แต่ว่าอย่างไรก็ดี การdesign program นั้น design framework, design patternsส่วนมากจะไม่ขึ้นกับภาษา คือ จะใช้ในภาษาไหนก็ได้ เช่นเดียวกับ algorithm
         ดังนั้นเมื่อต้องถึงเวลาที่จะเปลี่ยน platform ไม่ว่าจะเป็นการไปใช้ platformตระกูลใหม่ (เช่น windows->linux, windows->macหรือว่ากลับกันก็ตาม) หรือว่าตระกูลเดิม แต่ update architectureใหม่จนจำไม่ได้ (เช่น windows 3.11->windows 95, win32->.net หรือmac os 9->mac os x) ก็ตาม สิ่งที่ต้องทำก็คือ
         – เรียนรู้ syntax และลักษณะเฉพาะของภาษาใหม่ (ถ้าจำเป็น)
         – เรียนรู้ basic ของ framework ของ platform นั้นๆ (เช่น การเรียกใช้component, การใช้ memory, ฯลฯ)
         จากนั้นในการเขียนโปรแกรมหรือว่าสร้าง application อะไร ในภาพรวม ก็คิดตามหลักprogram design เดิม และใช้ algorithm ตัวเดิม แต่ว่าเรียกใช้ componentจาก framework ตัวใหม่ (ซึ่งตรงนี้ ถ้า basic แน่นดี ก็เปิดดูจากreference ได้เลย) และอาจจะปัญหาเรื่องรายละเอียดปลีกย่อยนิดหน่อยในส่วนที่เป็นลักษณะเฉพาะของภาษาใหม่ ที่ต่างไปจากภาษาที่เคยชินเท่านั้นเอง เช่นตอนที่เขียน objective-c ใหม่ๆ งงกับมันอยู่พักนึง กับsemi-automatic memory management ของมัน เพราะว่าเคยแต่ใช้ manual แบบc/c++ หรือว่า fully automatic แบบ java
         ส่วนถ้าใครอยากจะลองเล่นกับmanaged c++ ก็หาตัวอย่างได้ทั่วไปครับ ส่วนหนังสือเล่มที่อยากจะแนะนำนอกจากหนังสือของสำนักพิมพ์ microsoft ที่น่าจะเป็นมาตรฐานที่ต้องอ่านแล้วก็มี Developing Applications with Visual Studio.NET โดย RicardGrimes เล่มนี้จะเน้นการใช้ Managed C++และจากพูดถึงส่วนของรายละเอียดต่างๆ ข้อเหมือนและข้อแตกต่างระหว่างmanaged c++ กับ c++และ c# ไว้ดีพอสมควรทีเดียว แต่ว่าอาจจะไม่มี codeตัวอย่างมากนัก เหมาะกับคนที่เขียนโปรแกรมเป็นอยู่แล้ว