ไปเจอมา เอามา 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 ได้) กลับไม่ดีขึ้นเท่าที่ควร (และแย่ลงด้วยในบางกรณี)

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

ตอนนี้เริ่มเล่น Leopard ในฐานะของนักพัฒนาโปรแกรมและพวกชอบงัดแงะมากขึ้น และตอนนี้เท่าที่ลองเล่นก็เจอปัญหาโน่นนี่นิดหน่อย ซึ่งได้ post ไว้ใน ThaiMacDev เรื่อยๆ แต่ว่าขอรวบรวมไว้ตรงนี้อีกที่หนึ่งละกัน

• ปัญหา libGL.dylib ใน Leopard
• ปัญหา libTIFF.dylib ไม่ตรงสถาปัตยกรรม
• Build libreadline 5.2 ใน Leopard

ไว้เจอมากกว่านี้แล้วจะ post ไว้เรื่อยๆ ครับ

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

ThaiMacDev.com

เรื่อยๆ นะครับ ตอนนี้ก็เพิ่งจะมีเรื่องประสบการณ์การแก้ปัญหา libGL.dylib แต่ว่าถ้ามีเรื่องใหม่ๆ (โดยเฉพาะการเล่นกับ API ด้วยตัวเอง และการรีวิว Xcode กับ Interface Builder ใหม่) ก็จะเขียนลงในนั้นเช่นกัน

ช่วงนี้ตรวจข้อสอบเด็กเยอะแยะ ตาลาย ไม่พอ ยังไม่วายเข้าไปดูตาม webboard หลายที่ …​ ก็เจอเรื่องที่คาใจมาน้านนาน คือ มักที่จะเจอคนเรียก IDE หรือ Editor ปนกับชื่อภาษาโปรแกรม โดยเฉพพาะเมื่อตัว IDE นั้นๆ มันดันมีชื่อภาษาปนอยู่ด้วย เช่น

• ภาษา Turbo C
• ภาษา Dev-C++
• ภาษา Visual C++
• ภาษา RadRails
• ยังมีอีก ฯลฯ

ซึ่งอ่านไปอ่านมาก็ตลกดี คิดในบางแง่มันก็อาจจะ make sense เนื่องจาก

• ภาษาหลายภาษา (เช่น C, C++) เป็นเพียงแค่ข้อตกลง ข้อกำหนด เท่านั้น บางอย่างก็จะเป็น vendor-specific โดยเฉพาะในจุดที่ไม่นิยามในตัวข้อกำหนดมาตรฐานจริงๆ (undefined by standard) ซึ่งจะทำให้ภาษาเหล่านี้แตกต่างกันไปตาม vendor
• Vendor หลายเจ้า โดยเฉพาะ Microsoft มักจะมีปัญหาประจำแหละ เรื่องนี้ คือไม่ได้ implement C++ ของตัวเองตามมาตรฐานของ C++ เสียทีเดียว อะไรหลายๆ อย่างที่มันถูกต้องตาม standard C++ ก็ไม่ถูกใน C++ ของ Microsoft
• บางทีมันก็เป็นเรื่องของ library ด้วย คือ vendor หลายเจ้ามักจะ implement อะไรหลายๆ อย่างเพิ่มเข้าไปจากที่จำเป็นต้องมีอยู่แล้วใน standard library (ถ้าเป็น C ล่ะก็ ตัวยอดนิยมคงจะไม่พ้น itoa() ใน stdlib.h กระมัง)

แต่ว่ายังไงๆ ก็ตาม เราก็น่าจะเรียกตามชื่อ vendor ของมันมากกว่าจะเรียกตามชื่อ IDE ไม่ชื่อหรือ ไอ้พวก “ภาษา ​Turbo C” นี่คงไม่เท่าไหร่ เพราะว่า implementation ของ C ตามแบบนั้น คงจะไม่มีคนทำ IDE ขี้นมาใช้นอกจาก Turbo C เอง (แต่ว่าก็ไม่แน่ เพราะว่าจริงๆ ก็สามารถทำ modern IDE ขึ้นมาเรียกการทำงานของส่วน compiler ใน Turbo C ก็ได้)จริงๆ แล้ว Borland ก็มี compiler สำหรับ Windows นะ ให้ใช้งานได้ฟรีๆ นะ แต่ว่าเป็น command line ซึ่งจำเป็นต้องหา IDE มาครอบใช้งานเอง (เช่น JFE หรือ CPad ผมเคยใช้แต่ตัวหลัง ตัวแรกลองแล้วไม่ค่อยชอบ) โดยสำหรับตัว compiler ตัวนี้ผมเข้าใจว่าตัวนี้เป็น compiler ตัวเดียวกับที่ใช้ใน C++ Builder แต่ว่าไม่แน่ใจ เพราะว่าไม่มี C++ Builder แต่ว่านั่นแหละ ถ้าเป็นตัวเดียวกันจริง ก็จะมีคนเรียกมันว่า “ภาษา C++ Builder” แทนที่จะเป็น “ภาษา C++ ของ Borland” (Borland’s implementation of C++)เช่นเดียวกับการเรียก “ภาษา Visual C++” แทนการเรียก “ภาษา C++ ของ Microsoft” (Microsoft’s implementation of C++)แต่ว่าเจ้า “ภาษา Dev-C++” นี่สิ เรื่องใหญ่ ทั้งๆ ที่เรียกใช้งาน GNU GCC ซึ่งเป็น GNU’s implementation of C/C++ นะ … Misleading มากเลย

อ้างอิง: Blognone: REST vs. SOAP Web Services โดย krunapon

ผมอ่านข่าวนี้ที่ blognone ด้วยความรู้สึกอยากจะตะโกนในใจว่า Take the Red Pill! Welcome to the Real World! ยังไงก็ไม่รู้

ใช่ครับ ถึงมันจะไม่ใช่ข่าวที่มีการประกาศใหญ่โตมโหฬาร (แบบ MS, Sun, IBM หรือว่าบริษัทชื่อใหญ่ๆ โตๆ ออกมาให้การสนับสนุนหรือว่าจับมือกันให้ความร่วมมือในเรื่องอะไรสักอย่าง) ที่อาจจะ catch ความสนใจและ convince คนที่อยู่ใน mainstream ได้ง่ายกว่า แต่ว่าก็ดีเหมือนกันที่คนเริ่มลืมตามองความเป็นจริงอันโหดร้ายของ SOAP-based Web Services มากขึ้น

ในหลักการแล้ว SOAP มันก็เป็น protocol ที่ดีนะ แต่ว่าในความเป็นจริงแล้ว เนื่องจากความต้องการของการใช้ Web Services ในปัจจุบัน มันเป็นการเข้าถึง resource แบบ CRUD เสียเป็นส่วนมาก การใช้งาน SOAP-based ในความรู้สึกของผม มันเลยกลายเป็นการขี่ช้างจับตั๊กแตนไปโดยใช่เหตุ และจะต้องมีองค์ประกอบอะไรต่างๆ มากมาย อีกทั้งปัญหาอย่างหนึ่งที่ตามมาในโลกความเป็นจริง ก็คือ ความหลากหลายของข้อมูล ความร้อยพ่อพันแม่ของ representation ทำให้การกำหนดมาตรฐานของ SOAP นั้น นับวันมันจะมีแต่ใหญ่ขึ้น และ bloated ขึ้นอย่างใช่เหตุ …. วิธีการ scale ของ SOAP มันสร้างความยุ่งยากและลำบากเอาเรื่อง

ก็เลยทำให้ตัว S ใน SOAP ซึ่งควรจะย่อมาจาก Simple กลายเป็นเรื่องตลก เพราะว่ามันเป็นทุกอย่าง ทุกอย่างจริงๆ นอกเหนือจาก Simple มันมีทุกอย่าง นอกจาก Simplicity

ที่เขียนนี่ ไม่ได้แปลว่า SOAP ไม่ดี หรือว่า REST คือคำตอบสำหรับทุกอย่างนะ ใครที่รู้จักผมจะรู้ดีว่า สำหรับกรณีแบบนี้ ผมแทบไม่เคย claim คำว่า 100% เพราะว่า exception มันมีแทบทุกเรื่องน่ะแหละ ยากที่จะหาอะไรบางอย่างที่มันเป็นจริงในทุกกรณี .. แต่ว่า exception มันจะต้อง catch และ handling แยกต่างหาก ไม่ใช่ยกมาพูดเป็น counter example หักล้างกับ general cases อยู่เรื่อยไป จนลืม handling กรณี “ทั่วไป” (general cases) อีก 80% ของกรณีทั้งหมด… เช่นกรณีนี้ คือ (น่าจะกว่า) 80% ของความต้องการการใช้งาน Web Services ในปัจจุบันนั้นคือ request resources แบบ remote ซึ่ง REST มันดีกว่าจม และไปอยู่บน (= ใช้ความสามารถของ) protocol ที่มาตรฐานมาก คือ HTTP อีกตะหาก

ในขณะที่บริษัทใหญ่ๆ ที่ชอบนั่งกำหนด standard ก็ยังคงบ้ากับ SOAP-based standard spec กันต่อไป บริษัทใหญ่ๆ ที่ต้องทำงานให้บริการข้อมูลจริงในโลกความเป็นจริง เช่น Google หรือ Amazon (ที่ Web Services มีผลอย่างมากกับ model ทางธุรกิจของตัวเองด้วย) กลับมีแนวโน้มจะกลับมาใช้ REST เพิ่มขึ้นเรื่อยๆ นี่ยังไม่นับถึงบริษัทเล็กๆ อีกนับร้อยนับพัน ที่ต้องให้บริการข้อมูลจริง เชื่อมโยงจริง ใช้งานจริง เป็นส่วนหนึ่งของระบบนิเวศน์ของข้อมูลขนาดใหญ่จริง .. ที่ใช้งาน WS แบบ REST มากกว่าที่จะเลือก SOAP (คนใช้ SOAP มันก็มีนะ ไม่ใช่ไม่มี)

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

และ SOAP vs. REST ก็เป็นอีกบทพิสูจน์หนึ่ง …. ที่ยังคงดำเนินต่อไป

ปล. จริงๆ ผมเคยเขียน blog เรื่อง SOAP หรือว่าทำนองบ่นๆ เรื่อง SOAP ไปแล้วหลายครั้ง

• WS-* ที่ blog เก่าที่ภาควิชา
• Google ยกเลิกการใช้งาน SOAP WS API ที่ ThaiMacDev
• Web Services Core Framework และ SOAP Services ที่ ThaiMacDev

เทอมหน้าวิชา WWW Programming ในส่วนของ Web Services จะสอน REST Web Services เป็นหลัก ส่วน SOAP คงจะยกยอดไป “ถ้ามีเวลา” แทน

[update 1]: ลืมไป ว่าเมื่อไม่นานมานี้ Tim Bray จาก Sun Microsystems ได้มาพูดถึง REST ไว้ด้วย และน่าสนใจทีเดียว และเขียนไว้หลายบทความ รวมถึงการให้สัมภาษณ์หลายครั้งด้วย ลองหาอ่านๆ ได้จาก blog ของเค้าครับ

• tbray.org (link นี้เฉพาะในส่วนของ Web Services Technology เท่านั้นนะครับ) ภายในแต่ละ link ค่อนข้างยาวทีเดียว น่าอ่านครับ
• InfoQ: Tim Bray on Rails, REST, XML, Java and More อันนี้สัมภาษณ์
• Tim Bray: Issues in Web Frameworks เป็น PDF ของ slide ที่ Bray ไปพูดเรื่องเกี่ยวกับ Web Frameworks ครับ มีเรื่อง Web Services ด้วย

[update 2]: เพิ่งอ่านที่ James Clark เขียนเรื่อง Bytes not Infosets ที่ remark น่าสนใจหลายเรื่องเหมือนกัน ที่อาจจะไม่เกี่ยวกับ SOAP vs. REST ตรงๆ แต่ว่าโดนหางเลข เนื่องจาก WS-* แบบ SOAP มัน emphasis กับ XML infosets มากเลย …. และ James Clark (คนที่เราน่าจะฟังมากที่สุดคนนึงในเรื่องของ XML) ก็มี remark ว่า

My conclusion is this: one aspect of the WS-* approach that should not be carried over to the REST world is the emphasis on XML infosets.

เห็นด้วยไม่รู้จะเห็นด้วยยังไง

[update 3]: minor clarifications added