Renovating rawitat.com

คิดว่าจะปรับปรุง rawitat.com ซะหน่อย เพราะว่าในส่วนของ blog นี่ ผมไปเปิด niche blog ที่โน่นที่นี่ซะเยอะแล้ว จนภถ้าจะเขียนเรื่อง Mac ก็ไปเขียนที่ TMGeeks หรือว่าถ้าจะเขียนเรื่องวิชาการ ผมก็อยากจะไปเขียนที่พวก blog วิชาการทั้งหลายทั้งแหล่ … ไม่แน่อีกไม่นานอาจจะเปิด niche website หรือว่า niche community blog เรื่องอื่นๆ อีกก็ได้

ดังนั้นผมก็เลยคิดจะปรับปรุง rawitat.com ใหม่ดังนี้

  • ทำเป็น website ส่วนตัวแบบถาวร (เข้าทำนองเดียวกับ web ส่วนตัวที่ภาควิชา แต่ว่าไม่ได้ปรับปรุงมานานแล้ว…. engine มันห่วย ปรับยาก)
  • ใช้ Drupal แทน WordPress
  • blog เรื่องส่วนตัวจริงๆ
  • blog เรื่องอื่นๆ ที่ยังไม่มี niche community site เป็นของตัวเอง
  • course material และ lecture note ทั้งหมดของผม ทั้งในมหาวิทยาลัย และวิทยากรรับเชิญ

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

สับสน … ชื่อภาษาโปรแกรม?

ช่วงนี้ตรวจข้อสอบเด็กเยอะแยะ ตาลาย ไม่พอ ยังไม่วายเข้าไปดูตาม 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 มากเลย

Clean RSS ที่เก็บไว้

ผมใช้ Vienna เป็น​ RSS reader ประจำ เนื่องจากมันใช้ค่อนข้างจะง่าย ฟีเจอร์ค่อนข้างจะครบ สำหรับการเป็น reader ธรรมดาทั่วไป (ก่อนหน้านี้เคยใช้ NetNewsWire Lite กับ NewsFire ก่อนที่จะเก็บตังค์)

พักหลังๆ นี่รู้สึกว่ามันจะ อืด มาก ส่วนหนึ่งอาจจะเป็นเพราะว่า feed ที่ผม subscribe ไว้มันเยอะจัด (ประมาณ 500 feeds) แล้วก็มี articles ที่เก็บไว้หลายหมื่น articles เพราะว่าผมไม่เคยให้มัน auto delete เลย (ด้วยความงก)

ว้นนี้เปิดเข้าไปดูใน ~/Library/Application Supports ที่มันน่าจะเก็บไฟล์ที่เก็บ feed เอาไว้ ตกกะใจกับขนาดมันมาก เพราะว่ามันตั้ง 300 กว่า MB (จำไม่ได้ว่าเท่าไหร่ แต่มากกว่า 350) อ่อ มิน่า มันก็เลยช้า ส่วนหนึ่งก็เพราะว่ามันจะต้อง load ไฟล์ฐานข้อมูลขนาดมหึมา (​มันใช้ SQLite storage นะ ที่รู้กันว่ามันค่อนข้างจะอืดถ้าข้อมูลมันเยอะ) ก็เลยต้องมานั่งจัดการมันซะมั่ง

ตอนนี้เหลือแค่ 70 MB เอง นี่แปลว่าข้อมูลที่เราลบทิ้งได้โดยไม่ต้องคิดอะไรนี่มันมากถึงกว่า 6/7 เลยสินะ นี่ขนาดผมยังไม่ได้สั่งให้ลบ articles ที่ผมยังไม่ได้อ่านนะ

จริงๆ ผมยังมี thought เกี่ยวกับ RSS และการ subscription ของ feed นิดหน่อย แต่ว่าตอนนี้ยังไม่มีเวลาเขียนถึง แล้วจะเขียนให้อ่านกันนะครับ .. เอาเป็นว่า ผมค่อนข้างจะเห็นด้วยกับ Daniel Jalkut แห่ง Red Sweater Software นะ ลองเข้าไปอ่านที่นี่ครับ

แต่เอาเป็นว่าตอนนี้ Vienna ก็กลับมา responsive อีกครั้งแล้ว ก็แน่นอน เบาสบายตัวไปเยอะนี่ รีดน้ำหนักที่ไม่ต้องการออกไปได้แล้ว คราวนี้คงต้องมานั่ง manage feed กันจริงๆ ซะที

Caps Lock บน Apple Keyboard ใหม่ แข็งเพราะจงใจ?

ตอนที่เขียน รีวิว Apple Keyboard ใหม่ ไปใน blog คราวก่อน ผมค่อนข้างจะบ่นเรื่องที่ปุ่ม Caps Lock มันแข็งกว่าปกติ ซึ่งก่อปัญหาให้กับผมเวลาใช้งานพอสมควร เนื่องจากตัวเองใช้ปุ่ม Caps Lock ในการสลับภาษาแบบเร็วๆวันนี้ไปเจอมา ว่าจริงๆ แล้วนี่อาจจะเป็น ความตั้งใจ ของ Apple ที่ทำให้ Caps Lock แข็งกว่าปกติ

อืมมม ถ้าเป็นเช่นนั้นจริง และลองคิดถึงว่า จริงๆ แล้วก็มีคนกดปุ่ม Caps Lock ผิดแบบไม่ได้ตั้งใจ (เพราะว่าคิดจะกด tab หรือ shift ด้านซ้ายมือ) เยอะพอสมควร … จะว่าไปปุ่ม Caps Lock มันก็เป็นปุ่มที่ใช้งานน้อยพอสมควรปุ่มหนึ่งล่ะนะ ดังนั้นถ้าจะมองจาก Usability design ที่จะป้องกันความผิดพลาดล่ะก็ มันก็ make sense อยู่ล่ะ คือ ถ้ากดผ่านๆ แบบแตะๆ มันก็จะไม่ถือว่าเรากด ดังนั้นต้องกดนานกว่าปกตินิดนึง ซึ่งก็จะทำให้จังหวะการพิมพ์มันเสียไปนิดหน่อย หรือว่ากดแบบเน้นๆ นิดนึง ซึ่งจะเปลืองพลังงานมากกว่าปกตินิดหน่อยสรุปว่า อืมมมม คนแบบผมมันคงจะเป็นส่วนน้อยล่ะนะ หรือว่าคนที่ใช้ปุ่ม Caps เพื่อวัตถุประสงค์ในการเปลี่ยนภาษาเร็วๆ นี่คงจะเป็นส่วนน้อย เพราะว่าถ้าจะพิมพ์ตัวใหญ่แค่ตัวสองตัว ก็คงจะกด shift เอามากกว่าอืมมม make sense ล่ะครับ แต่ว่าสำหรับการใช้งานส่วนตัว ผมยังอยากให้มันอ่อนเท่ากับ key อื่นๆ เหมือนเดิม (ส่วนหนึ่งเพราะลักษณะการใช้งานของผม และส่วนหนึ่งมาจาการที่ผมไม่เคยกด Caps ผิด) …​ แต่ว่าครั้งนี้ ถ้า Apple ได้วิเคราะห์พฤติกรรมของผู้ใช้แล้วจริงๆ ว่ามีการกด Caps ผิดแบบไม่ได้ตั้งใจเยอะพอ และปุ่ม Caps ก็เป็นปุ่มที่ใช้งานน้อยอยู่แล้ว … ดังนั้นการออกแบบคีย์บอร์ดมาแบบนี้ก็เหมาะสมดีอยู่

Web Services: REST vs. SOAP

อ้างอิง: 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 ไปแล้วหลายครั้ง

เทอมหน้าวิชา 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