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

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

HTML

CSS

JavaScript

Result

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

มาคุยกันเรื่อง Mobile Dev กันอีกสักรอบ ... ช่วงนี้ผมเห็น App หลายๆตัว เริ่มเปลี่ยนมาใช้ HTML5 กันมากขึ้น ซึ่งก็พอจพมองได้ว่าเป็นข่าวดี เพราะ HTML เป็น เทคโนโลยี ที่ ง่าย แล้วก็ ไปได้ทุก Platform

ก่อนหน้านี้ผมมีปัญหากับการเขียน App ใน Titanium คือมันมีปัญหากับ Table พอ เนื้อหายาวๆ แล้ว Scroll ขึ้นลงเร็วๆ มันจะกระตุก หน่อยๆ ไม่ค่อย นิ่มนวลเท่าที่ควร ก็เลยคิดว่า จะลองเปลี่ยนมาเป็น HTML5 ในส่วนของ Table + JS Scrolling เข้าท่าๆ สักตัว

แต่จนแล้วจนรอด ก็ไม่มีตัวไหนได้อย่างใจผมเลย

จน iOS update มาถึง v5 นี่แหละ ถึงได้รู้ว่า คิดถูกแล้ว

Scrolling ของพวก Mobile มันจะ มี โมเมนตั้ม ที่ต่างจาก การ Scroll ขึ้นลงของ Browser ค่อนข้างมาก เพราะฉะนั้น ถ้าเราเขียน HTML Table ธรรมดา ลงไปเป็น App ความรู้สึกมันจะรู้เลย ว่าไม่ใช่ แต่ วันนี้ Apple แก้ปัญหาให้เราแล้วล่ะครับ

แล้วทั้งหมดก็แก้ปัญหาด้วยคำว่า

สวัสดีครับ หายหน้ากันอีกไปพักใหญ่ๆ แต่ว่าก็ยัง อัพเดทอยู่ใน 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

ที่ท่านกำลังจะอ่านต่อไปนี้ เป็นเรื่องจริง ของตัวผมเอง ที่ไม่เคยตีพิมพ์ที่ไหนมาก่อน 5555

ผมไม่มีชีวประวัติเท่ห์ๆ อย่างเช่น

จบ IT Specialits จาก มหาวิทยาลัยชั้นนำของอเมริกา หรือว่า สร้างตัว จากเสื่อผืนหมอนใบ ไม่มีแม้กระทั่ง ปริญาตรี จากสาขา คอมพิวเตอร์ ที่ไหนทั้งนั้น แต่นี่คือสิ่งที่เกิดขึ้นกับผม จริงๆ !

"เขียนโปรแกรมเหรอ" ?

ตัวผมก็ไม่ได้เรียนเกี่ยวกับทางด้านนี้มาเลยนะ ไม่เคยคิดด้วยซ้ำ จบโฆษณามาล่ะ เพราะตอนเรียนมหาลัย ไม่ชอบเลข กับ ภาษาอังกฤษ ถึงขนาดเคยติด F ซะด้วยซ้ำ แถมจบช้ากว่า คนอื่นปีนึง เพราะว่าติดสาว 555

จบมาก็ไม่รู้จะทำอาชีพอะไร เพราะว่าโง่มาก ดีที่ตอนนั้นเห็นเว็บมันกำลังมา หันไปทางไหนมีแต่ คนเล่นเน็ท เลยหันมาศึกษา เพราะอยากรวยอย่างเดียว คิดว่า ทำเว็บเสร็จ สงสัยคนจะมาลงโฆษณาเยอะ (เคยเห็นค่าโฆษณาบางเว็บแล้วมันเยอะดี) ลงสัก 10 ป้าย ป้ายละพัน ได้สักเดือนละ 10,000 นึง โอ้ย แหล่ม มีตังค์เที่ยวแน่กู !!!

ก็เลยหัดเขียนเว็บแม่งเลยนี่ เดี๋ยวทำเว็บดังๆ รวยไม่รู้เรื่อง ฮ่า ฮ่า ฮ่า

ในใจตอนนั้นคิดว่า มันจะไปยากอาไร้

โอ้โห ไม่ได้อัพเดทบล็อกนี้ (มีบล็อกเดียว) มานานมากๆ เผลอแป๊บเดียว 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 วุ่นวายแบบนั้น เลยเขียนลวกๆ ง่ายๆ ออกมา ลองมาดูขั้นตอนกัน ง่ายมากๆ

สวัสดีครับ ภาค 2 มาซะทีนะครับ อิอิ

จริงๆ แล้วผมมีเรื่องอีกหลายเรื่องที่อยากจะมาเขียนทั้ง Yahoo Query Language (YQL) หรือว่าจะเป็น Zend JSON-RPC Server รวมไปถึง jQuery MVC แต่ก็อดใจไว้ เพราะกลัวว่าเรื่อง Titanium จะไม่จบแล้วก็ขาดความต่อเนื่อง ซึ่งผมกะๆ เอาโดยประมาณกว่าจะเขียนจนจบ คงมีเยอะแน่ๆ แล้วดูจากการ update ที่บ่อยมากๆ ของผม คงจะเขียนสัก ปี สอง ปีเป็นแน่แท้ 555

แต่เอาเถอะครับ ต่อจากนี้จะพยายามมาอัพเดทให้บ่อยขึ้นละกัน

วันนี้ก่อนที่เราจะมาลงมือเขียนจริๆ ผมอยากจะเล่าให้ฟังถึง โครงสร้างของ Titanium Mobile สักนิดนึง อย่าเพิ่งเบื่อกันไปก่อนนะครับ

เริ่มต้นตั้งแต่เรา Create Project ขึ้นมาใหม่ เราจะพบไฟล์ตามภาพด้านล่างนี้

โดยจะประกอบไปด้วย ไฟล์ Config, License, Readme แล้ว ก็ โฟลเดอร์ที่เราไว้ใช้ทำงาน คือ Resources

แล้วถ้าเราแตก Resources ออกมาดู (ตามภาพด้านล่าง) จะพบว่ามี ไฟล์ app.js นั่นล่ะครับ คือไฟล์แรกที่เราจะใช้ในการเขียน App ส่วนโฟลเดอร์ iphone, android คือที่ไว้เก็บไฟล์ ภาพเวลารัน App ขึ้นมาหรือไฟล์ที่เกี่ยวข้องกับ app โดยตรงเช่น icon app อะไรแบบนั้น

เอาล่ะครับ มาเข้าสู่โลกของ Mobile กันอีกครั้ง 555

วันนี้ผมจะมาเข้าเรื่องของ Titanium Mobile แล้วนะครับ โดยก่อนที่จะลงมือเขียนกันนั้น มาทำความรุ้จักคร่าวๆ กันก่อนว่า ไอ้เจ้า "Titanium Platform" เนี่ยมันคืออะไรกัน ?

Titanium เนี่ยเป็นเครื่องหมายการค้าของ Appcelerator, Inc. โดยมี Tool ที่เป็นจุดขายเลย คือเครื่องมือพัฒนา Software แบบ Cross-Platform และที่สำคัญคือเป็น Native App ด้วย

คำว่า Native App ก็หมายความ App ที่ออกมา จะมีลักษณะ เหมือนกับ App ที่พัฒนาด้วยภาษาต้นแบบเลย ประมาณนั้น โดยภาษาที่เขียนไม่จำเป็นต้องเป็นภาษา ที่ทาง Hardware แต่ละตัวกำหนด โดยที่ ตัว SDK ของ Titanium จะทำหน้าที่เป็นตัวกลางระหว่าง ภาษาที่เราเขียน กับ ภาษาที่ใช้งานจริงๆ ให้เราเอง พูดง่ายๆ ก็ลองนึกภาพ  API ละกัน แนวๆ นั้นแหละ

อ้าวแล้วทำไมเราต้องมาใช้  Titanium ล่ะ ?

จริงๆ ส่วนตัวผมเองตอนแรก มีคำตอบเดียว ก็คือ "มันง่าย" ไม่เสียเวลาดี แต่พอมาจับลึกๆ แล้วมันมีคำตอบที่ผมสรุปมาเองประมาณนี้ครับ

1. ภาษาที่ใช้ส่วนมากเป็น Web Skill ซึ่งผมคิดว่า เราๆท่านๆ ก็คงมีติดตัวกันมาพอสมควร จึงไม่เสียเวลามากนัก ในการเรียนรู้

2. ทำที่เดียวมันออกมาได้หลาย Platform อาทิเช่น เขียน Software บน  Windows ได้ของ Mac, Linux แถมมาด้วย หรือว่า เขียน iPhone ได้ Android ติดมือมาอีก (อาจจะมีแก้คำสั่งส่วน UI บ้าง)

3. มี Developer ใช้อยู่เยอะ พอสมควร App ใหญ่ๆ บางตัวก็ใช้ อาทิเช่น Ebay ทำให้มีความมั่นใจได้พอสมควรว่า จะไม่ถูกลอยแพ หรือว่า ตัดออกจาก สาระบบ ง่ายๆ

4. ฟรี ไม่ต้องเสียตังค์เพิ่มเติม แต่ถ้าอยากจ่ายคุณ ก็อาจจะได้  IDE ดีขึ้น Module API มากขึ้น ได้เข้าไปดูในส่วน Knowlegde Center มากขึ้น ราวๆ นี้

5. API ทำมาได้ล้อกับ Native Apps อย่าง  ได้ใกล้เคียงกันมาก แทบจะครบตามที่ต้องการ

เอาล่ะ 5 ข้อนี้ก็ พอสำหรับการตัดสินใจที่จะใช้งานแล้ว สำหรับผม ที่จะขาดไปบ้างก็มี 

1. Performance ไม่ได้ดีระดับ Native แต่ก็ถือว่าไม่น่าเกลียดไปนัก

2. ไม่มี Interface Builder แต่ข้อนี้ก็แก้ได้ ด้วยมีคนเขียนตัว Convert มาให้แล้วครับ สำหรับ Titanium Mobile นะ เดี๋ยวไว้จะเอามาแนะนำกัน

3. หาข้อมูลยากเหลือเกินครับ ถ้าไม่ยอมจ่ายตังค์ จะส่ง Ticket ไปถามก็ไม่ได้ แต่เรามันพวก คิวบู๊ อยู่แล้ว เรื่องแค่นี้ ไม่ง้อก็ได้วะ !

ก่อนที่จะลงมือเขียน iOS App นั้นเราต้องทำความเข้าใจก่อนว่า วิธีการเขียนนั้น มันไม่ได้มีวิธีการเดียว แต่มันมีถึง 3 วิธีด้วยกัน ซึ่งก็คือ Native, Web View, Hybrid โดยที่แต่ละตัวก็อาจจะมี ประเภทย่อยๆ แล้วก้ชนิดของมันลึกลงไปอีกบ้าง แต่ว่าไม่ใช่สาระสำคัญอะไร

ทีนี้ผมจะขออธิบาย ตามความเข้าใจแบบ งูๆ ปลา ของผมก่อน แล้วกัน ถูก ไม่ถูกยังไง ก็ขอให้เข้าใจไว้ว่า ผมมัน "มือใหม่"

1. Native App

App ประเภทนี้ก็คือ App ที่เขียนตาม Rules ของ Apple ล้วนๆ คือใช้ Xcode พัฒนาโปรแกรมด้วย Objective C แบบตรงๆ ซึ่งผลที่ได้ก็คือ Performance ดีเยี่ยม ความเสี่ยงที่จะไม่ได้รับการ Support เป็น 0 อภิสิทธิ์ เหนือชั้น

แต่ข้อเสียมันก็คือ ต้องไปเสียเวลาพอสมควรในการ Learning แล้วพอ เรียนจนฉลาดแล้ว แม่งก็ทำอะไรได้ไม่กี่อย่าง เพราะภาษามันเฉพาะเหลือเกิน

แต่ทว่าก็ไม่อยากให้ทิ้ง อยากให้เป็นตัวที่เราพยายามเรียนรู้ไป ในขณะที่กำลังเขียนในรูปแบบอื่นๆ

2. Web View

อันนี้เป็นตัวเลือกในกรณีที่เราต้องการ App แบบเร่งด่วน แล้วก็ไม่ต้องการลูกเล่นอะไรมากมายนัก ไม่จำเป็นต้องติดต่อกับ Feature ภายในตัวเครื่อง ภาษาที่เขียนก็ Web Skill ล้วนๆ ครับ เขียนเสร็จก็เอา Native เรียก URL ตรงๆ มาเลยก็เสร็จแล้ว ไม่จำเป็นต้อง Learning อะไรใหม่เลย ถ้าคุณเป็น Web Dev อยู่แล้ว

โดยที่คุณอาจจะมีตัวช่วยหน่อยก็คือพวก Mobile Web Framwork อย่าง jQTouch, jQuery Mobile, Sencha Touch เพื่อให้มันดูโปรขึ้นมาอีกนิด

แล้วก็ความคิดเห็นส่วนตัว ถ้าให้ผมเลือกใน 3 ตัวนี้ผมเลือก Sencha ครับ เพราะความดูมัน Look Native ที่สุด

ข้อเสียก็คือ App มันดู ป๋องๆ แป๋ง ใช่มั้ยล่ะ ? แล้วก็ติดต่อกับ Feature เช่นพวก  กล้อง, Location Base, Network อะไรพวกนี้ไม่ได้เลย !!!!

แล้วก็ความเร็วของ App มันจะไปผูกกับ Web Server แทบจะ 100% เลยทีเดียว แต่มันก็สะดวกและเร็วมากๆ คุณอาจจะเอามาเป็นตัวเลือกแรก ในการหัดทำแรกๆ ก็ไม่เสียหายหรอก