JSFIDDLE เป็น Tools สะดวกมากๆ สำหรับเขียน เทสต์ Script หรือว่า ส่งต่อตัวอย่าง หรือว่าจะประยุกต์ทำอะไรก็แล้วแต่

โดยที่ Tools ตัวนี้จะแบ่ง กล่องเริ่มต้นมาให้เรา ทั้งหมด 4 กล่อง แบ่งเป็น

HTML

CSS

JavaScript

Result

โดยที่เราสามารถเขียนสามารถเขียนโคด ตามแต่ละส่วน แล้วผลลัพธ์ก็จะออกมาที่ ส่วน "Result" ที่สำคัญ Tools ตัวนี้ ยังอนุญาติให้เรา Load พวก JS Framework ต่างๆ เข้าไปเพื่อทำการเทสต์ร่วมได้ด้วย โดยที่เราจะใช้ Sources ที่เค้าเตรียมมาให้ หรือว่าจะ link ตรงเข้าไปเพิ่มเอง ก็ยังได้

สวัสดีครับ หายหน้ากันอีกไปพักใหญ่ๆ แต่ว่าก็ยัง อัพเดทอยู่ใน Fan Page อยู่เรื่อยๆ นะ แต่ว่าถ้าเป็น บทความยาวๆ นี่มันท้อ แฮะ 555

แต่วันนี้ ยังไงก็มาแล้ว ก็จับประเด็น บางเรื่องมาเล่าสู่กันฟัง...

พอดีช่วงนี้ผมกำลัง ทำงานในส่วนออก Report พอดี ซึ่งที่ต้องการก็คือ ออก Report เป็น PDF อันที่จริงมันก็ไม่มีปัญหาอะไรหรอก Lib PDF มีอยู่ถมไป Zend_Pdf ซึ่งทำงานได้ละเอียดมากๆ ก็มีอยู่ แต่ด้วยความขี้เกียจ เลยไม่อยากไป Add Columns ไปสร้างสี แบ่งล๊อกอะไรให้มันวุ่นวาย

แล้วก็จำได้ด้วยว่าเคยเห็น Web ตั้งเยอะที่มัน Convert HTML เป็น PDF มันน่าจะมีใครทำ Lib อะไรมาให้ใช้บ้างน่า สรุปได้ แคนดิเดท มา 3 ตัว ประกอบไปด้วย

1. TCPDF

2. Dompdf

3. mPDF

ก็เลยค่อยๆลอง ไปทีละตัว โดยที่แต่ละตัว ก็มีข้อเด่น ข้อด้อยต่างกันไป ซึ่งแรกเริ่ม ผมก็ไล่มาเลย ตั้งแต่

TCPDF

ตัวนี้ค่อนข้างจะใช้ง่ายมาก ไม่ต้อง Config อะไรวุ่นวาย Font ก็มี ที่ Support ภาษาไทยมาให้ในตัว คือ "Freeserif" ไม่ต้องทำอะไรเท่าไหร่ ตอนแรกก็คิดว่าจะหยุดที่ตัวนี้แหละ แต่พอทำไปทำมาเกิดปัญหา คือมันสามารถอ่าน Stylesheet ได้แค่เล็กน้อยเท่านั้น พวก attrs ง่ายๆ อย่าง  color อะไรแบบนี้

แต่ว่ามันดันอ่านพวก float, padding, margin เพี้ยนๆ ไม่เหมือน HTML ที่ทำมาเท่าไหร่ ซึ่งมันยากมาก เพราะผมต้องทำ HTML เป็น table เกือบทั้งหมด เลยเปลี่ยนๆ ลองตัวใหม่

Dompdf

ตัวนี้ลองอ่าน Document แล้ว ก็ลองใช้งาน ถูกใจมากเลย ถึงจะ config ลำบากไปนิด แต่ว่าใช้งานง่าย โคดเขียนสวย Doc มีตัวอย่างเยอะ แล้วก็ดู ค่อนข้างโปรที่สุด แต่....

พอถึงเรื่องภาษาไทย ผมพยายาม Add Font ไทยเข้าไป มันก็ได้อยู่ ถึงจะลง Font ค่อนข้างลำบากหน่อย แต่พอเอามา Render จริงๆ font ไทย เนียนนะครับ ใช้ได้หมด แต่สระ เสือกกลายเป็น สี่เหลี่ยมหมด (คิดว่าคงมีวิธีแก้ แต่ตอนนี้ไม่ได้หาต่อแล้ว) ก็เลยข้ามไปก่อน กะว่าจะมาหาวิธีแก้ ที่ตัวนี้แหละ แต่ยังไงขอลอง ตัวถัดไปก่อน

วันนี้ผมเอาลิ้งก์แนะนำ การเขียน JavaScript ตาม Pattern แบบต่างๆ มาแนะนำ ซึ่งค่อยข้างแปลกสักหน่อย คือผมมา อัพบล็อกแต่ไม่อยากเอา บทความเค้ามาแปล เพราะว่า กลัวจะแปลไม่ถูก 555

แต่ว่า บทความนี้มันดีจริงๆ ผมเลยต้องเอามา บล็อกกัน ทั้งๆ ที่ Copy มาเป็นลิ้งก์แบบนี้แหละ

บทความเค้าเป็นเรื่องเกี่ยวกับ JS Pattern แบบต่างๆ รวมไปถึง ข้อแตกต่าง ของแต่ละรูปแบบ ส่วนตัวสำหรับผม มันน่าสนใจมากๆ แล้วก็มีประโยชน์ที่จะ ทำความคุ้นเคยเอาไว้

เพราะ JS ในปัจจุบันมัน ค่อยข้างจะแทรกซึมไปทุกที่ ทั้ง HTML5, Mobile Framework, API Protocol, Push Engine แล้วก็อีกล้านแปด ในอนาคตนี้ก็ไม่มีทางตายง่ายๆ นับวันมีแต่จะใหญ่โตขึ้นเรื่อยๆ

ก็ลองๆดูๆ กันหน่อยนะ วันนี้ขออัพเดท แบบคนขี้เกียจสักหน่อย 555

โอ้โห ไม่ได้อัพเดทบล็อกนี้ (มีบล็อกเดียว) มานานมากๆ เผลอแป๊บเดียว 4 เดือนเข้าไปแล้ว ก็มันขี้เกียจนี่หว่า ไว้จะทำ Screen Cast แทนไม่รู้จะลำบากขึ้นมั้ย 555

เอาล่ะ ไหนๆ ก็อัพ แล้ว เอาเรื่องที่หาอ่าน บทความภาษาไทย ไม่ค่อยได้ดีกว่า เรื่องของ "Web Service"  ครับ ปกติส่วนมากจะมีแต่บทความวิธีใช้ แต่ว่า วันนี้ผมจะมาเขียน บทความ "วิธีทำ" กันดีกว่า

สมัยนี้ หนียังไงก็หนีไม่พ้น กับการต้องเข้าไปยุ่งกับ API ของเว็บบิ๊กๆ ทั้งหลาย ซึ่งแต่ละเว็บก็มีการใช้ Protocol ต่างกันไป ถ้ายิ่ง บิ๊กมาก ก็จะมี Protocol ให้ใช้แทบจะครบ

มีทั้ง RESTful, XML-RPC, JSON-RPC, SOAP, etc. ซึ่งลงท้ายทุกตัวทำงานเหมือนกันหมด คือใช้ติดต่อ ระหว่าง โปรแกรม ซึ่งตอนนี้ API ของเว็บทุกเว็บ อย่างน้อยจะต้องมี  1 protocol คือ REST เพราะว่ามันง่ายกับ Developer ในการติดต่อ แล้วก็เขียนเชื่อมไป จะว่า XML-RPC, JSON-RPC ก็ต้องถือว่า เป็น REST ด้วยเหมือนกันแหละ เพียงแต่ Response Format ต่างออกไป

เอาล่ะ ทฤษฎีอาจจะไม่ค่อยแน่น แต่ปฎิบัติ ผมพอไหว  555

วันนี้เราจะมาออกแบบ ชุด API ของ REST กัน โดยที่โจทย์ของเรามีดังนี้

1. API จะต้อง Authen จากโปรแกรมเชื่อมใช้งานได้

2. Structure ต้องเป็นระเบียบสามารถเพิ่ม ชุด function ได้ง่าย

3. Response ต้องออกได้ทั้ง XML และ JSON

4. ต้องมี Failed Message  ในกรณีที่ API ไม่สามารถทำงานได้สมบูรณ์

อุปกรณ์เครื่องครัวที่ต้องเตรียมมา

1. CodeIgniter ตัวนี้ใช้เป็น Base Render MVC เฉยๆ จะมีไม่มีก็ไม่ว่ากัน เอา Structure ตามถนัด

2. Zend_Rest_Server ตัวนี้ก็เหมือน เนื้อสัน ไม่มีก็ทำ เสต๊ก ไม่ได้

3. Zend_Json ตัวนี้เอาไปแปลง Response Format  กลับไป กลับมาระหว่า XML -> JSON

เอาล่ะ มาเริ่มกันเลย....

ก่อนอื่นเราต้องมี File Bootstrap ของ API คือตัวกลางนั่นแหละ เวลาที่ ใครเรียกจะต้องมาที่ไฟล์นี้ก่อนซึ่งตัวนี้ผมใช้ Controller นั้น CI  มาทำ

โดยในไฟล์นี้ผมตั้งชื่อ Controller ว่า Rest.php

เบื่อเรื่อง mobile กันรึยังครับ จริงๆ ตอนแรกว่าจะเขียนเรื่อง Table ของ Ti  ต่อเลย แต่คิดว่า มันต้องลำดับความคิดเยอะเกินไป วันนี้อยากเขียนอะไรเบาๆ ที่ใช้เวลาไม่เกิน 20 นาที เลยเอาเรื่อง Facebook ง่ายๆ มาคั่นเวลาไปก่อนละกัน

จริงๆ แล้วการทำ oAuth ของ Facebook เพื่อ Request Access Token นั้น ตัว SDK มันก็ทำงานได้ค่อนข้างดีแล้ว แต่ว่า บางทีก็ขี้เกียจ implement วุ่นวายแบบนั้น เลยเขียนลวกๆ ง่ายๆ ออกมา ลองมาดูขั้นตอนกัน ง่ายมากๆ

ปฎิเสธไม่ได้ว่านี่เป็นช่วงตกต่ำของเว็บไซต์ระดับโลกอย่าง Yahoo! ล่าสุดเว็บ Delicious ก็กำลังจะถูกขายไปในไม่ช้า (เว็บโปรดกรู T__T) แต่ว่า Yahoo! ก็ยังมีของดีๆ ให้กับ Developer ที่ไม่ใช้ระดับโลกอย่างเราๆ ท่านๆ ใช้ 555+

สำหรับบทความวันนี้เราจะพูดกันถึง Tool สำหรับนักพัฒนาที่สุดแสนสะดวกในยามขี้เกียจตัวนึง นั่นก็คือ

YQL (Yahoo! Query Language)

ซึ่งถ้าเราให้คำจัดกัดความของมัน มันก็คือ "API สำหรับ APIs" นั่นเอง เพราะตัวมันทำหน้าที่ต่อในการเรียกใช้ APIs ตัวอื่นๆ ด้วยภาษที่คล้ายๆกับ SQL ทำให้เราไม่ต้องทำความเข้าใจกับขั้นตอนซับซ้อนอะไร ของ API ปลายทางมากนัก

และที่สำคัญ Yahoo! จะเป็นคนจัดการเรื่อง Performance ต่างๆ ให้เราเองอีกด้วย ซึ่งตัว Yahoo! บอกไว้ว่าไอ้ Service นี้ของเค้าน่ะ มันมี Uptime ถึง 99.5% เชียวนะ แต่มันก้มีข้อจำกัดเรื่อง Rate Limit ว่า Query ได้ไม่เกิน 100,000 ต่อวัน และไม่เกิน 1000IP/ชั่วโมง แต่ก็ช่างแม่งเหอะ -*-

โดยที่ตาราง Table (ให้มองภาพเหมือน SQL) มี 2 แบบก็คือ

บทความนี้ไม่ได้คิดขึ้นเองทั้งหมดนะครับ แต่ประยุกต์มาจากบทความของฝรั่ง ที่ไปอ่านมา แล้วต้องบอกเลยว่าตรง โคดๆ แล้วก็ไม่ได้ว่าใครด้วยนะครับ แต่ว่าอยากให้มองในมุมกลับกันมากกว่า แล้วก็เปลี่ยนแปลงทีละเล็กละน้อย เราก็จะก้าวพ้นกับคำว่า Noob ได้แล้ว

ที่จะเขียนต่อไปนี้ คือฟฤติกรรมที่บ่อนทำลาย อาชีพ Dev ของตัวเอง อย่างเห็นได้ชัด (จริงๆ มันก็ไม่ขนาดนั้นหลอก แต่ฝรั่งมันเว่อร์ 555)

ทีนี้มาดูกันถึง 10 ตัวอย่างของ โปรแกรมเมอร์ยอดแย่ ที่ควรจะแก้ไขโดยด่วน

1. ชอบเขียนแบบสั้นๆ เอาสะดวก

วิธีการเขียนโคดสั้นๆ แบบนี้ จริงอยู่ที่มันประหยัดเวลา แล้วมันก็แสดงผลได้ถูกต้อง แต่ว่ามันขาดความเป็นมืออาชีพ แล้วก็บางอย่างทำให้ PHP ต้องเสียเวลาแปลมากขึ้นไปอีก แทนที่จะทำงานได้เลย แล้วก็ไม่ดีต่อการ Portable ย้าย Server ข้ามไปข้ามมา เพราะว่า บางที่ Compile ได้ไม่เหมือนกัน เพราะฉะนั้น ต้องขอบอกเลยว่า "เขียนให้มันเต็มๆ" เถอะครับ

อาทิเช่นการออก output

เริ่มต้นของเรื่องนี้ เกิดมาจากความต้องการที่ไม่สมหวังของผมเอง 555+

คืดผมอยากจะ Convert YouTube มาเป็น ไฟล์ MP3 ไว้ฟังเองเล่นๆ (มันผิดกฎหมายลิขสิทธิ์ แล้วก็ผิดกฎของ YouTube นะจ๊ะ) ก็เลยไป Google เพื่อหา เว็บที่จะ Convert ให้ แบบ Online แต่พอหาๆ ไปมันก็พอมีอยู่หรอก แต่ว่า
เพลงที่ผมจะเอามันดันมี เสียงอะไรเยอะแยะ ก่อนจะเริ่มเพลง ทีนี้ไอ้เว็บพวกนี้มันก้ไม่ยอมให้เลือกเวลา เริ่มต้น สิ้นสุด อะไรแบบนั้น ซึ่งแต่ก่อนผมใช้เว็บนึงมันมีให้ แต่พอดีมันเจ๊งไปแล้ว ไม่รู้โดนจับหรือยังไง 555+

ก็เลยเอาวะ เขียนเองแม่มเลย จะได้ใช้วันหลังด้วย !!!

กลับมาตามสัญญากับ บทความ jQuery วันนี้จะมาพูดถึงเรื่อง Ajax กันสักเล็กน้อย สมัยนี้แล้ว Ajax มันเป็นพื้นฐานของ Web Developer ไปซะแล้ว เพราะมันง่ายแล้ว ก็ไม่มีอะไรซับซ้อนอีกต่อไป เพราะว่าเรามี Tool ดีๆ ไว้ทำงานเยอะ นั่นเอง

แต่ว่า...

จะมีใครมองไปถึงรายละเอียดเล็กๆ น้อยๆ ของมันแล้วทำการปรับปรุง คุณภาพการใช้งานให้ดีขึ้นรึเปล่า นั่นเป็นอีกเรื่องนึง ที่มักจะถูกมองข้าม

ซึ่งจริงๆแล้วปัญหา ของมันก็พอจะมีให้เห็นอยู่หลายๆส่วน ซึ่งที่ผมจะมาเล่าวันนี้ เป็นเรื่องของเทคนิคล้วนๆ ไม่ใช่ปัญหา แบบที่เป็น ปัญหาทางอ้อม อย่างพวก SEO หรือ Pageviews อะไรแบบนั้นนะ ไอ้นั่นผมเถียงมาจนเบื่อละ -*-

ปัญหาที่มักจะพบบ่อยก็คือ Request ค้างบ้าง, ทำงานตอบสนองไม่ได้บ้าง, หรือว่าโดนยิง Request จาก Clients โดยไม่เจตนาบ้าง

ปัญหาเหล่านี้ มันไม่ใช่ปัญหาอะไรใหญ่อะไร แต่ถ้าแก้ไขได้ มันก็ดีไม่ใช่เหรอ ??

ซึ่งอันที่จริงแล้วปัญหานี้ผมนึกขึ้นมาได้ตอนที่ทำ Ajax Gallery เล่นๆ ตัวนึง เพื่อนๆ ลองนึกภาพตามผมถึงธรรมชาติของ User ในการเปิดดู Gallery นะครับ ผมจะลองเรียงลำดับมาให้ ตามด้านล่างนี้ ...

ต่อจากคราวที่แล้วเราพูดกันไปเรื่องของ การตัดคำ (ไม่รู้มีใครเอาไปทำอะไรบ้างยัง) มาคราวนี้ก็จะเป็น ภาคต่อ ของการนำไปประยุกต์ใช้กับระบบ ภายในเว็บไซต์ นั่นก็คือ เทคนิคการทำ Search นั่นเอง

สำหรับ การทำระบบค้นหาแบบ Full text นั้น ถ้าจะให้เห็นภาพกันก็ลองนึกถึงพวก Search Engine อาทิเช่น Google โดยที่เราสามารถทำการค้นหาเข้าไปแบบไหนก็ได้ ไม่ใช่ค้นหาเหมือนกับที่ส่วนใหญ่เราทำในระบบ เว็บไซต์พื้นฐานทั่วไป

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

การทำระบบ Search แบบนี้จะถูกคิดออกมาเป็น Score ซึ่ง ข้อมูลที่มี Score ดีกว่าจะเข้าถึงผู้ใช้งานได้มากกว่า

โดยการทำแบบนี้จริงๆแล้วมีมาตั้งนานมากๆ แล้วอาทิเช่น Sphinx, Lucene แต่ติดที่ว่ามัน Implement ค่อนข้างยากไปหน่อย แต่ตอนนี้ผมจะมาพูดถึงทางลัดกัน นั่นก็คือเจ้าเก่า Zend นั้นเอง

โดยวันนี้เราจะหยิบเอา Zend_Search_Lucene มาทำงานกัน

ผมจะขอลำดับบทความออกเป็น 2 ส่วน และถ้าไม่หมดแรงไปซะก่อนจะอธิบายให้จบรวดเดียวไปเลย โดยแบ่งออกเป็นดังนี้