~[แปล] มารู้จักกับ Functional Programming สิ่งที่คุณต้องรู้ในปี 2015 กันเถอะ

ย้ายบทความไปอยู่ที่ http://www.tamemo.com/post/80/functional-programming-should-be-your/ แล้วล่ะ

[แปล] ภาษาและเฟรมเวิร์คไหนบ้างที่ Developer ควรจะศึกษาประจำปี 2015

พอดีไปอ่าน The Languages And Frameworks That You Should Learn In 2015มาก็เลยเอามาแปลและเรียบเรียงใหม่ อาจจะไม่เหมือนต้นฉบับมากนักนะ

Language / Platforms 

สำหรับภาษาโปรแกรมปีนี้น่าจะเป็นปีของ Node.js ที่มาแรงมากจนทิ้งห่างจาก php ที่เป็นอันดับ2ไปเลย JavaScript ก็ยังคงอยู่ในลำดับต้นๆ แต่มี Swift เพิ่มเข้ามาในอันดับต่อไป

Framework

Laravel ยังคงอยู่แต่มี Ruby on Rails แซงไปพร้อมกับการที่กูเกิลเปิดตัว(นานแล้ว)และโปรโมท Angular JS ทำให้มันเป็นสิ่งที่น่าจับตามองนะ

มาดูตัวสำคัญๆ กัน

JavaScript

ตอนนี้เราสามารถพบเห็น JS ได้เกือบทุกที่จากสมัยก่อนที่มันทำงานอยู่แค่เบราเซอร์ฝั่ง client แต่หลังจากที่ Node.js เปิดตัวมามันก็แสดงให้เห็นว่า JS เอาไปเขียนในฝั่ง Serverได้ด้วยนะ
ข้อดีของ JS คือมันเป็นภาษาที่เขียนได้ง่ายทำให้เรียนรู้ได้เร็ว แต่ข้อเสียคือมันเขียนได้ง่ายเกินไป บางครั้งก็ทำให้กลายเป็นเรื่องยุ่งยากได้ และการที่มันยังไม่มีคำสั่งในการสร้าง Class แบบจริงจังก็ทำให้มันเขียน OOP ได้ไม่ค่อนถนัดเท่าไหร่นัก ... แต่อย่างว่า มันกระจายตัวไปทุกที่แล้วดังนั้นก็เป็นตัวเลือกที่ควรจะเรียนรู้ไว้

AngularJS

JS Framework (เห็นมั้ยว่าเป็น JS อีกแล้ว)  เอาไว้ทำ interactive website ซึ่งทำและสนับสนุนโดย Google ล่าสุดทำคอร์สติวเตอร์ให้ด้วย เข้าไปดูได้ทาง shaping up with angular.js
จุดเด่นของ Angular คือเน้นความสนใจไปที่ข้อมูลContentในหน้าก่อนจะไปสนใจ DOM ถ้าใครเคยเขียน jQuery หรือแม้แต่ JS แบบดั้งเดิม การเขียนแบบนั้นจะเป็นการเขียนในลักษณะของ "How!" คือวางDOMให้เสร็จแล้วค่อยบอกว่าจะให้มันทำอะไรยังไง
แต่ถ้าเป็น Angular ละก็จะใช้วิธีวางข้อมูลก่อน แล้วค่อยจัดการ DOM ข้อดีคือเราไม่ต้องไปบอกว่าจะให้ทำอะไรยังไงละเอียดเท่าพวก jQuery ดูเป็น Framework มากกว่า แต่ต้องจำคำสั่งและ config ให้ถูกด้วยนะ
แล้วถามว่ามันดีกว่า jQuery มั้ย? อันนี้ก็ต้องบอกว่าแล้วแต่ชอบ แต่ Angular น่าจะให้งานได้เร็วกว่า jQuery เพราะมันแทบจะไม่ต้องเขียนโปรแกรมส่วนที่เป็น logicเลย ตัว Frameworkจ ัดการให้หมดแล้ว เราแค่เซ็ตค่าคำสั่งให้ถูกก็พอ แต่ข้อเสียคือถ้าเป็นโปรแกรมที่ซับซ้อน jQuery น่าจะยังได้เปรียบกว่า

React

เป็น JS Library อีกตัวที่น่าสนใจสำหรับสร้าง user interface โดย Facebook + Instagram ถ้ารูปจักโครงสร้างแบบ MVC แล้วละก็ การอธิบายว่า React คือ V น่าจะเข้าใจได้ง่ายกว่า
การเขียน React จะเขียนอยู่ใน <script type="text/jsx"> ซึ่งแน่นอนว่ามันไม่ใช่ JS เพียวๆ แต่เป็น JS ที่เราสามารถใส่ view (ในรูปของ XML + HTML เข้าไปได้เลย)
ลองไปดูตัวอย่างได้ที่ React

Node.js

สร้าง network server application ด้วย JS ซึ่งตอนนี้มี framework ออกมาให้ใช้เยอะมากตั้งแต่ Express, websocket การลงโมดูลใหม่ก็ทำได้ง่ายผ่านการใช้งาน npm
Node.js ใช้ JS ดังนั้นมันเลยทำงานแบบ asyncronous ซึ่งทำให้เวลาได้รับ request มาแต่ละตัวจะไม่จำเป็นต้องรอกัน

NoSQL Database

ฐานข้อมูลแบบ Relational แบบเดิมที่เดิมข้อมูลเป็นตารางอาจจะไม่ตอบโจทย์รูปแบบข้อมูลตอนนี้ได้แล้ว Not Only SQL จึงเกิดขึ้นมารองรับแทน และเสริมด้วยการที่พวกมันทำ Scalable ได้ด้วย
ตัวที่เด่นๆ ก็มี mongoDB (document) กับ redis (key-value)

Less / Sass / Stylus

ฝั่ง script มีการพัฒนากันไปไกลแล้ว ด้านฝั่ง css เลยทำบ้าง (ทำมานานแล้วแหละนะ) เพื่อทำให้เขียน css ได้ง่ายและสั้นขึ้น อีกทั้งยังใช้พวกตัวแปรได้ด้วย แต่ส่วนใหญ่เวลาเอาไปใช้จริงจะ compile ออกมาเป็นไฟล์ css อยู่ดีนะ

Classic Full-Stack Framework

เฟรมเวิร์คระดับคลาสสิกที่ก็ยังใช้ได้อยู่ ไม่ได้ล้าสมัยแต่อย่างใด เช่นพวก Laravel (php), Ruby on Rails (Ruby), ASP.NET

แล้วก็อย่าลืมพวก php, Wordpress, jQuery ด้วยนะ พวกนี้เป็นวิธีที่ค่อนข้าง perfect ในการสร้างเว็บไซท์

โดยเฉพาะ Wordpress ที่โตอย่างรวดเร็วมากในช่วงที่ผ่านมา

[แปล] User eXperience (UX) - ตอนที่ 2 สร้างตัวแทนผู้ใช้กับ Persona

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

สมมุติว่าทีมได้รับมอบหมายให้ออกแบบรถคันหนึ่ง ลองคิดภาพตามว่าจะเกิดอะไรขึ้นถ้าคุณจะออกแบบรถออกมาอย่างไรที่ทำให้คนทุกคนบนโลกพึงพอใจมากที่สุด

สิ่งที่จะเกิดขึ้นก็คือรถคันนั้นจะเต็มไปด้วยฟังก์ชั่นทุกอย่างที่คนอยากได้ แต่..

ไม่มีใครอยากใช้มันล่ะ!

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

“I don’t know the key to success, but I know the key to failure is trying to please everybody”

(เราไม่รู้หรอกว่าหนทางสู่ความสำเร็จคืออะไร ... แต่เรารู้ว่าหนทางสู่ความล้มเหลวก็คือการพยายามทำให้ทุกคนชอบมัน)

ลองจินตนาการต่ออีกหน่อยว่าถ้าคุณได้รับมอบหมายให้ไปแก้ปัญหาในร้านอาหารเหตุหนึ่งนะ

คุณเลือกที่จะทำอะไร ระหว่าง

- สร้างเมนูอาหารที่หลากหลาย 30 จานที่มั่นใจว่าลูกค้าไม่ว่าจะมีรสนิยมแบบไหนก็ต้องถูกใจสักจาน

หรือ

- ลดเมนูอาหารจาก 30 จานให้เหลือเพียงแค่ 10 จาน และทำ 10 จานนั้นให้มีคุณภาพที่ดีที่สุด

สรุปก็คือ ไม่ต้องพยายามทำให้ Product ของเราตอบสนองความต้องการของลูกค้าทุกคนหรอก ขอแค่ทำบางอย่างเพื่อให้ตอบสนองต่อความต้องการของคนให้ถูกกลุ่มแบบเฉพาะเจาะจงไปก็พอแล้ว

มารู้จักกับ Persona กัน

ในฐานะคนสร้าง Product แล้วเราก็ต้องการออกแบบให้ตรงความต้องการของลูกค้ามากที่สุดใช่มั้ยล่ะ เพราะถ้าลูกค้าพอใจก็ปิดจ๊อบเร็ว (และรับเงินเร็ว 555)

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

ดังนั้นเราจะสร้างสิ่งหนึ่งขึ้นมาเป็นตัวแทน User ทีนี้เวลาประชุมก็เลิกคิดซะทีว่าเราอยากได้อะไร แต่ให้เปลี่ยนเป็น เจ้าตัวแทนผู้ใช้คนนี้น่ะมันอยากได้อะไร!!

[แปล] User eXperience (UX) - ตอนที่ 1 อะไรคือUXกันนะ ทำไมถึงสำคัญนัก

พอดีที่ออฟฟิศมาเปิดคอร์ส UX User Experience: The Ultimate Guide to Usability โดย Dr David Travis ซึ่งจริงๆ มันเป็นคอร์สเสียเงินแต่บอสใจดีออกค่าเรียนให้ เลยขอเอาที่ดูมาสรุปไว้ในบล๊อกนี้ละกัน

เวลาเราจะสร้างโปรแกรมขึ้นมาโปรแกรมหนึ่ง (หรือออกแบบดีไซน์อะไรบางอย่าง) ไม่ว่าจะเป็นโปรแกรมแบบ Desktop Web หรือ Mobile ก็ตาม คนส่วนใหญ่มันจะคิดถืงแต่ "ความสวยงาม" เป็นหลัก

อ้าว พูดงี้แล้วมันไม่ถูกเหรอ ออกแบบออกมาถ้าสวยก็ทำให้คนประทับใจได้ก่อนแล้วนะ แบบ First Impression ไงล่ะ

ก็ถูกนั่นแหละนะ แต่...

เคยไหม ... โหลดแอพมาเล่นเพราะดูจากใน preview แล้วแอพมันสวยเหลือเกิน แต่พอโหลดมาใช้แล้วกลับมาความรู้สึกว่ามันยังไม่ใช่ แล้วก็ไม่เปิดมันมาใช้อีกเลย
และเคยไหม ... แอพอะไรก็ไม่รู้ โหลดมาเล่นๆ ดีไซน์ไม่สวยเอาซะเลยแต่เรากลับเปิดใช้มันทุกวัน

การดีไซน์productออกมาให้สวยงามมันไม่ได้แปลว่ามันจะน่าใช้หรอกนะ เราต้องคิดด้วยว่าถ้าเราเป็น User แล้วเจอโปรแกรมแบบนี้ เราจะชอบมันหรือไม่อยากเปิดมันมาใช้อีกเลย

แยกให้ออกระหว่าง UX กับ UI

UX (User eXperience) กับ UI (User Interface) เป็นสิ่งที่ดีไซน์เนอร์มือใหม่หลายคนไม่เข้าใจมัน
เพราะการออกแบบโปรแกรมไม่เหมือนกับการออกแบบสื่อสิ่งพิมพ์ (โปรแกรมมันต้องมีการตอบโต้กับผู้ใช้ แต่พวกสื่อสิ่งพิมพ์คนอ่านจะมองแต่ภาพ ถ้าเห็นแล้วคิดว่าสวยก็ถือว่าใช้ได้)

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

มีภาพชุดหนึ่งที่เราเห็นว่าเขายกตัวอย่างข้อแตกต่างระหว่าง UX กับ UI ได้ดี เป็นภาพจาก design.org เราลองมาดูกัน

ในตัวอย่างนี้เขาเปรียมเทียบโปรแกรมของเราเป็น "อาหารเช้าคอนเฟล็ก" การใช้ของก็ง่ายๆ คือเอาไว้กินล่ะนะ (ฮา)

ตัวแรกสุดคือ Product หรือก็คือตัวแทนโปรแกรมที่เราจะออกแบบนั่นแหละซึ่งในที่นี้ก็คือถ้วย ช้อน และคอนเฟล็ก (อาหารเช้าแบบซีเรียลรับประทานพร้อมนมสด)

ดังนั้น ขอถามว่าเราจะกินคอนเฟล็กพวกนี้ยังไงกัน?
คำตอบก็คือใช้ส่วนติดต่อกับผู้ใช้ User Interface ซึ่งในที่นี้มันคือ "ช้อน" นั่นเอง!

เอาล่ะ การออกแบบ UI ที่ดีก็คือการออกแบบเจ้าช้อนนี่ให้มันสวยงาม อาจจะเป็นช้อสแตนเลสมีลายอะไรประมาณนั้น ผู้ใช้จับช้อนขึ้นมาแล้วอาจจะร้องว้าว ช้อนสวยจังอะไรทำนองนี้

แต่ความสวยงาม (UI) ที่พูดไปเมื่อกี้อาจจะไม่มีประโยชน์เลยถ้าเกิดว่า User ไม่ได้สนใจความสวยงามพวกนั้น เพราะเขากำลังหิว!

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

ลองคิดดูสิ ว่าถ้าคุณอาจจะตักคอนเฟล็ก แล้วเราเอาช้อนเล็กๆ แต่สวยนะ ดีไซน์ดีสไตล์มากให้คุณ คุณอาจจะชอบมันในตอนแรกที่ได้รับ แต่พอลองตักอาหารดูแล้วก็จะเริ่มพบว่ามันตักยาก ตักนมก็ไม่ได้ คุณก็จะเริ่มหงุดหงิดแล้วเดินไปหาช้อนใหญ่ๆ มาใช้แทนโดนไม่สนว่าช้อนมันจะดีไซน์เป็นอย่างไรจริงไหม

พอเห็นภาพแล้วสินะว่า UX มันคือการออกแบบที่คิดถึงจิตใจของ User มากๆ โดยไม่สนใจความสวยงามเลย (แต่ก็ใช้ว่า ไม่มี UI ได้นะ ถึง UX จะดีงามแต่ถ้ามันไม่สวย User ก็ปิดทิ้งได้เหมือนกันนา)

ใครคิดว่าตัวเองแน่! ลองไปเล่นเกมหาบั๊กโปรแกรมที่ codefights.com

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

วันนี้เราเลยมีเกมมาให้ลองเล่นกันดู นั่นคือ How Fast Can You Debug?

กดเข้าไปเล่นได้ที่นี่เลย

เข้าไปปุ๊บก็จะเจอกับหน้าตาเกมประมาณนี้ คือพอกดเริ่มเล่น มันจะมีโค้ดโปรแกรมสั้นๆ มาให้ 1 ชุดแบบนี้ไงล่ะ เท่าที่เล่นดูน่าจะมีแต่ภาษา JavaScript (ไม่ใช่ Java นะจ๊ะ)

หน้าที่ของคุณไม่มีอะไรมากหาให้เจอว่าโค้ดเนี้ยมันผิดตรงไหน แล้วก็แก้ให้ถูกซะ คำแนะนำคือพยายามเดาจากชื่อ function ก่อนว่าโค้ดชุดนี้มันทำหน้าที่คำนวนอะไร

แต่ถ้าเดาไม่ออกจริงๆ ก็ลองอ่าน comment ที่มันเขียนไว้ข้างบน มันจะบอกอยู่แล้วว่าโค้ดชุดนี้กำลังทำอะไร มีบอก input กับ output ที่ต้องการครบเลย

แต่ช้าก่อน!!

อย่าเพิ่งนิ่งนอนใจไปนะ เพราะมันให้คุณแค่ข้อละ 60วินาที เท่านั้น!! ยิ่งตอนเหลือ10วินี่ลุ้นระทึกมากเพราะตัวเล่นจะเด้งไปเด้งมา (ฮา)
และจากที่เล่นมา ไม่ใช่ว่าเราแก้ตรงไหนก็ได้นะ คุณแก้ได้แค่ 1 บรรทัดเท่านั้น

ถ้าแก้ถูก ก็จะได้คะแนนตามความเร็วที่หาเจอ แล้วมันก็จะให้โค้ดชุดต่อไปมา เราก็ต้องแก้ไปเรื่อยๆ จนกว่าเราจะผิด

ซึ่งมันผิดได้ง่ายมากเลยนะ ไหนจะพิมพ์ผิด Syntax Error กดเร็วไปหน่อย บลาๆๆ เพราะมันไม่มีปุ่มให้เอาใหม่นะ กดส่งคำตอบแล้วถือว่าจบ

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

~ [แปล] รู้ไหมว่างานอะไรที่ทำให้โปรแกรมเมอร์ปวดหัวกับมันที่สุด?

บทความนี้ย้ายบล๊อกไปอยู่ที่ http://www.tamemo.com/post/61/9-hardest-things-programmers-have-do/ แล้วนะ กดเพื่ออ่านต่อได้เลย

~หลายๆ วิธีที่จะทำให้คุณเขียนโปรแกรมเก่งขึ้น

ตอนนี้ย้ายบล๊อกไปอยู่ที่ TAmemo.com::หลายๆ วิธีที่จะทำให้คุณเขียนโปรแกรมเก่งขึ้น

[How to] แชร์ Facebook แล้วรูปไม่ขึ้น ต้องการจะให้มัน fetch หารูปของเราใหม่ ทำยังไง?

บางครั้งเวลาเรากดแชร์ Facebook แล้วปรากฏว่าเจ้า Facebook มันดันไปหารูปอะไรก็ไม่รู้มาแสดงเป็นภาพ shared image ทั้งๆ ที่รูปเจ้าปัญหารูปนั้นก็ไม่ได้อยู่บนหน้าเว็บสะหน่อย (อาจจะเคยมีอยู่แต่ลบไปแล้วกดแชร์ใหม่มันก็ยังอยู่)

เพราะมันติด cache! ยังไงล่ะ

อะไรคือ cache? แคชเป็นสิ่งที่คล้ายๆ กับความจำชั่วคราว เก็บไว้ไม่นาน (แต่บางครั้งมันก็นานได้ แล้วแต่จะตั้งค่า) แล้วระบบการทำงานของ Facebook เมื่อมีคนกดแชร์ ก็คือเจ้าระบบของเว็บ Facebook มันจะวิ่งมาที่ url หน้าที่เราจะแชร์ของ ถ้ายังไม่เคยมีอยู่ในข้อมูลมาก่อนเลย มันก็จะทำการหารูปในหน้าเว็บนั้นมาให้เราเลือกว่าจะเอารูปไหน

แต่ประเด็นคือ ... ถ้าเป็นการแชร์ครั้งที่สอง เว็บ Facebook มันจะไม่วิ่งมาหารูปใหม่แล้วเพราะมันมี image cache เก็บเอาไว้จากครั้งที่แล้วแล้วยังไงล่ะ สาเหตุก็เพราะความเร็วในการแสดงผลเป็นหลัก

ดังนั้นปัญหามันเลยเกิดขึ้น!

แล้วถ้าเราอยากจะเปลี่ยนรูปใหม่ล่ะ ทำยังไง

เข้าไปเคลียร์ cache ซะสิ

ก่อนอื่นเลยก็เข้าไปที่หน้านี้ https://developers.facebook.com/tools/debug/og/object/

เราจะเจอช่องให้ใส่ url ที่ต้องการจะเคลียร์แคชทิ้ง ก็ใส่ url ของหน้าเว็บเราลงไปแล้วกดปุ่ม [Fetch new scrape information] ซะ

เท่านี้ Facebook ก็จะไปดึงข้อมูลรูปภาพใหม่อีกครั้ง

url สำหรับ developer

ระบบของ Facebook อนุญาตให้เราส่ง query string ไปเคลียร์แคชได้เลยเช่น

[How to] วิธีเซฟไฟล์ word ให้กลายเป็น .pdf

ไฟล์เอกสารจากโปรแกรม MS Word เป็นไฟล์ที่นิยมใช้กันมาก แต่มันก็มักจะมีปัญหาอยู่ เช่นเวลาส่งไปให้เพื่อน เอาไปสั่งปริ๊นที่ร้าน ฟอร์เมทตัวอักษรที่จัดไว้มักจะ "เพี้ยน" จนต้องไปนั่งจัดหน้ากันใหม่

การ save ไฟล์ .doc และ .docx ให้กลายเป็นไฟล์ .pdf ซึ่งเป็นไฟล์ที่สามารถเปิดอ่านได้อย่างเดียว แก้ไขไม่ได้ (และแน่นอน ไม่ว่า ฟอนต์ รูป การจัดหน้าจากไฟล์ต้นฉบับจะเป็นอย่างไร มันจะคงอยู่เป็นแบบนั้น) ดูจะเป็นทางเลือกที่มั่นใจได้มากที่สุด

แต่ก่อนที่เราจะเซฟไฟล์เป็น .pdf ให้ไปโหลดปลั๊กอินของเวิร์ดเพิ่ม ที่นี่ <-- จิ้มเบาๆ

เว็บต้นทางของไมโครซอร์ฟเลย ดังนั้นมั่นใจปลั๊กอินตัวนี้ได้ ... ก็โหลดลงมาแล้วก็จัดการติดตั้งให้เรียบร้อย (กด nextๆๆ ไปเรื่อย~)

วิธีใช้งาน

ในตัวอย่างเราสร้างไฟล์ .doc ขึ้นมา ถ้าลงปลั๊กอินแล้ว เวลากด save as จะเห็นหัวข้อ "PDF or XPS" เป็นตัวเลือก

หลังจากกดปุ๊บก็จะเจอหน้าเซฟไฟล์ตามระเบียบ

เพียงเท่านี้ก็จะได้ไฟล์ .pdf จากเอกสารเวิร์ดเราแล้ว ส่งไปให้ใครก็ไม่ต้องกลัวไฟล์จะเพี้ยน

~ ก่อนจะทำให้โปรแกรมฉลาดได้ โปรแกรมเมอร์ต้องฉลาดก่อน

ย้ายบทความไปอยู่ที่ http://www.tamemo.com/post/46/before-smart-program/

~หลายๆ เหตุผลที่ ทำไม๊ ทำไม..ก็เขียนโปรแกรมไม่เก่งซะที

ตอนนี้ย้ายบล๊อกไปอยู่ที่ TAmemo.com::หลายๆ เหตุผลที่ ทำไม๊ ทำไม..ก็เขียนโปรแกรมไม่เก่งซะที

.htaccess ใช้งานไม่ได้ ขึ้นแต่คำว่า "No input file specified."

เมื่อวันก่อนเจ้าของบล๊อกได้ทำการย้ายไฟล์จาก host ตัวเก่าไปยัง host ตัวใหม่อีกตัว
ซึ่งปกติแล้วเว็บที่เราใช้ก็เป็น framework ตัวหนึ่งที่โมฯ ขึ้นมาใช้เอง
และแน่นอนว่า framework ส่วนใหญ่มักจะมีการจัดการ url-decoration เพื่อความสวยงามให้

ตัวอย่างเช่น CI หรือ CodeIgniter ก็จะสั่งให้ทุกอย่าง redirect ไปหา index.php แล้วทำการเซ็ตไฟล์ .htaccess ให้ re-write เจ้า index.php ออกไปจาก url เช่น

RewriteEngine on
RewriteCond $1 !^(index\.php|images|robots\.txt)
RewriteRule ^(.*)$ /index.php/$1 [L]

หรือถ้าเป็น Laravel ก็จะเป็น

Options +FollowSymLinks
RewriteEngine On

RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.php [L]

ทีนี้เวลาเราเรียก จาก

www.nainee.com/index.php/view/1234

ก็จะเหลือแค่

www.nainee.com/view/1234

เท่านั้น ดูสวยขึ้นเยอะ!
นับเป็นวิธีการทำให้ url ดูสวยงามเรียกง่ายขึ้นที่นิยมที่สุด

แต่ทว่า...

อย่างที่เกริ่นไปข้างต้น เรากำลังทำการย้าย host อยู่ แน่นอนว่าเมื่อย้ายไปแล้วก็ต้องมานั่งปรับๆ อะไรกันนิดหน่อยตามฟอร์มเพราะเซิร์ฟเวอร์แต่ละตัวมันตั้งค่ามาไม่เหมือนกัน

แต่ผิดที่โค้ดภาษา PHP ยังพอว่าแต่นี่แม้แต่เรียกหน้าเพจยังไม่ขึ้นเลย แจ้งมาแต่คำว่า

No input file specified.

อ้าว เจออย่างนี้เราก็งงน่ะสิ ของเก่าไอ้เจ้า .htaccess มันยังทำงานได้ปกติเลย แล้วนี่มันเกิดอะไรขึ้น?
คือบอกก่อนว่า .htaccess ที่เขียนน่ะมันไม่ผิดชัวร์ เพราะที่ host เก่ามันทำการ re-write ได้ไม่เห็นมีปัญหา

แล้วแก้ยังไงล่ะ?

ทางแก้นั้นไม่ยากเลย แต่ใช้เวลาหานานมาก นั่นคือ...
เพิ่ม ? ลงไปข้างหลัง path ที่เราจะให้ re-write ไปหา
เช่น

RewriteEngine on
RewriteCond $1 !^(index\.php|images|robots\.txt)
RewriteRule ^(.*)$ /index.php?/$1 [L]

เพียงเท่านั้นแหละ .htaccess ก็จะกลับมาใช้งานได้เหมือนเดิม
จบ!

~ปัญหาของคน(เริ่ม)เขียนเว็บ ... HTML CSS JavaScript PHP SQL อยากได้แบบนี้ต้องใช้อะไรเขียน?

บทความนี้ย้ายที่ไปอยู่บล๊อกใหม่แล้วล่ะ ตามไปอ่านได้ที่ http://www.tamemo.com/post/30/

~[How to] วิธีปิด Skype และทำให้มันไม่ทำงานทันทีทุกครั้งที่เปิดเครื่องมาใหม่

ตอนนี้ย้ายบล๊อกไปอยู่ที่นี่แล้วครับ แต่บทความยังอยู่นะ ตามไปอ่านบทความต่อได้ที่:
กดเลย --> http://www.tamemo.com/post/28/

~camel case VS snake case .. สไตล์การเขียนโค้ด 2 แบบที่เจอบ่อย

ตอนนี้ย้ายบล๊อกไปอยู่ที่นี่แล้วครับ แต่บทความยังอยู่นะ ตามไปอ่านบทความต่อได้ที่:
กดเลย --> http://www.tamemo.com/post/20/

~ภาษาไหนดี? (Programming Language)

คอนนี้ย้ายบล๊อกไปอยู่ที่ใหม่แล้ว ตามไปอ่านได้ที่ http://www.tamemo.com/post/14/

~Web Developer Tools แนะนำเครื่องมือประจำกายนักเขียนเว็บ

ตอนนี้ย้ายบล๊อกไปอยู่ที่ใหม่แล้ว ตามไปอ่านได้ที่นี่ http://www.tamemo.com/post/5/

~แนะนำโปรแกรมสำหรับใช้เขียนเว็บ

บทความนี้ย้ายไปอยู่ในบล๊อกใหม่แล้ว ตามไปอ่านได้ที่นี่ http://www.tamemo.com/post/5/

~วิธีตั้งค่า netbeans IDE ให้รันภาษา C/C++ ได้

บทความนี้ย้ายไปอยู่ในบล๊อกใหม่แล้ว ตามไปอ่านได้ที่นี่ http://www.tamemo.com/post/3/

ข้อคิดดีๆ เวลาคุณจะเขียนโปรแกรม

1. เขียนโปรแกรมครั้งหนึ่ง จงเขียนให้เล็กที่สุดเท่าที่จะเป็นไปได้
2. จงโปรแกรมโดยคิดว่าจะมีคนมาเขียนต่อจากเรา เพราะอย่างน้อยที่สุดหลังจากเรามาเปิดดูมันอีก1ปีต่อมาเราจะได้อ่านมันรู้เรื่องอยู่
3. clearance (ความชัดเจน) กับ extensibility (การขยายต่อได้)...เราเลือกได้อย่างเดียว ต้องตัดสินใจดีๆ 
4. อย่าไว้ใจ output จากfunctionอื่น แม้functionนั้นเราเป็นคนเขียนเองก็ตาม เพราะมีโอกาสที่เราจะทดสอบfuncที่เราเขียนขึ้นมาไม่ดีพอ
5. ถ้าโปรแกรมเมอร์เขียนเองแล้วยังไม่เข้าใจว่าตัวเองทำอะไรอยู่ ก็อย่าไปขอให้คนอื่นช่วยเลย ขอไปเขาก็ไม่เข้าใจอยู่ดี ทางที่ดีลองพักสักครู่หนึ่ง กลับไปทำความเข้าใจมัน ถ้ายังไม่ได้อีก...ก็ตั้งสติแล้วเริ่มเขียนใหม่ดีกว่า อย่าเสียเวลากับอะไรที่แก้ไขไม่ได้แล้วเลย
6. หาข้อมูลสามวันก่อนลงมือทำหนึ่งวัน หรือจะลงมือทำเลยแล้วแก้บั๊กสามวันก็เลือกเอา ข้อมูลในที่นี้รวมไปถึงการขั้นตอนการออกแบบตัวโปรแกรม flowchart data structure ที่จะใช้อะไรพวกนั้นทั้งหมดเลยนะ
7. เตรียม tools framework program-environment ก่อนลงมือทำงาน ไม่เช่นนั้นคุณจะหงุดหงิดเวลาจะทำอะไรแล้วไม่ได้อย่างใจเมื่อเคย
8. อย่าโทษหรือโยนความผิดให้functionหรือclassอื่นก่อน โดยเฉพาะเมื่อพวกมันมาจาก OS และ compiler
9. พยายามทำตามกฎอย่างเคร่งครัด แต่ถ้าทำไม่ได้ก็เลี่ยงให้น้อยที่สุดพร้อมกับประกาศไว้ให้เด่นที่สุด
10. High cohesion, Loose coupling ตามหลักของSoftware Engineering-โมดูลและฟังก์ชั่นต้องยึดเกาะให้แน่นที่สุดในตัวของมันเอง และผูกกับโมดูลอื่นให้น้อยที่สุด
11. เก็บ หรือวางสิ่งที่คล้ายๆ หรือเหมือนกันไว้ให้ใกล้กันที่สุด แม้ในแง่ของการเขียนโปรแกรมที่ลำดับไม่สำคัญต่อการรันผลก็ตาม เพราะคนเขียนนั่นแหละที่จะงงเมื่อเขียนไปเป็นพันๆ บรรทัดแล้ว ไม่ใช่คอมหรอกที่จะงง
12. พิสูจน์ก่อน...แล้วค่อยเชื่อ
13. กระจายความรู้ออกไปให้มากที่สุดเพราะนั่นคือการทำ Unit Test ระดับล่างที่สุด
14. อย่าเอาทุกอย่างใส่ลงไปในUI เพราะUIคือส่วนที่ทำ Unit Test ได้ยากมาก
15. โปรเจคทั้งโปรเจคควรไปในทางเดียวกัน (ต้องมีConsistency)
16. ถ้ามีสิ่งดีๆ ให้ใช้อยู่แล้วก็จงใช้มัน แต่ถ้าจำเป็นต้องเขียนเอง...ก่อนจะเขียนก็ควรศึกษาความผิดพลาดในอดีตของคนอื่นก่อน
17. อย่ามั่นใจว่า code ชุดนี้ใช้ได้ดีจนกว่าจะTestเพียงพอ (ขนาดTestพอแล้วยังเจอบั๊กได้เลย)
18. มีการ edit version ของโปรแกรม ให้รันUnit Testใหม่ทุกครั้ง
19. แต่ก็อย่าเชื่อ Unit Test ให้มากนัก บางครั้งมันก็ผิดได้
20. ถ้าคุณเขียน code อะไรซ้ำกันมากกว่า1ครั้ง มันก็เพียงพอแล้วล่ะที่จะหาวิธีลดรูปหรือแยกชุด code นั้นออกมาเขียนเป็น function
21. อย่าเขียนโปรแกรมไปโดยคิดว่าจะoptimizeมันไปด้วย เขียนให้มันใช้งานได้ก่อนแล้วค่อยลงมือทำ แล้วถ้าไม่จำเป็นก็อย่าไปoptimizeมันเลย
22. ประสิทธิภาพของโปรแกรม แปรผกผันกับความเข้าใจง่าย...ถ้าโปรแกรมทำงานได้ดีมากเชื่อเถอะว่า code จะเริ่มอ่านยากแล้ว
23. เวลาเขียน จงใช้ pattern ที่ชาวบ้านเขาใช้กัน เวลาเอาไปคุยกับคนอื่นจะได้คุยรู้เรื่อง
24. MutiThreading เป็นการเพิ่มประสิทธิภาพ แต่มันจะมาพร้อมกับ Concerency, Deadlock, IsolationLevel, Hard to debug, Undeterministic Errors.และอื่นๆ อีกมากมาย
25. อย่าไปเพิ่มtechnologyโดยไม่จำเป็นให้โปรแกรมเรา เพราะคนเป็นโปรแกรมเมอร์จะวุ่นวายมากขึ้น
26. โปรเจคทำอะไรอยู่คิดซะว่าอาจจะมีความเปลี่ยนแปลงได้ตลอดเวลา (เช่น requiementเปลี่ยน)
27. อย่าย่อชื่อตัวแปรโดยไม่จำเป็น มันจะทำให้คุณงงในตัวเอง ตอนนี้โปรแกรมIDEมันฉลายขึ้นเยอะแล้ว แค่พิมพ์ตัวแรกมันก็ขึ้นhintมาให้เลือกแล้ว
28. ถ้าโปรเจคใหญ่มากอย่าใช้ i, j, x, y, result, name, param เป็นชื่อตัวแปรยกเว้นคุณจะมีหลักการเขียนที่ตัวเองจำมันได้แน่นอนว่า พวกมันเก็บค่าอะไร
29. แบ่งแยกดีดี ระหว่าง Exception message ในแต่ละเลเยอร์ ว่าต้องการบอกผู้ใช้ หรือ บอกโปรแกรมเมอร์
30. ที่ระดับ UI ต้องมี catch all exception เสมอเพื่อกรอง Exception ที่ลืมดักจับ
31. เวลาทำงานกับdatabase ระวังcolumnที่เป็นnullให้ดี เรื่องนี้ทำโปรแกรมเมอร์เจ็บมากหลายต่อหลายคนแล้วเพราะค่าnullมันconvertไม่ได้
32. อย่าลืมว่า Database เป็น global variable ประเภทหนึ่ง แต่ละโปรแกรมที่ติดต่อเปรียบเหมือน MultiThreading ดังนั้นกฏของ Multithreading ต้องกระทำเมื่อทำงานกับ Database
33. ระวังอย่าให้ ฟอร์มของif then else ที่ซ้อนกันมากมาก...สมองคนไม่ใช่ CPU จินตนาการไม่ออกหรอกว่ามันอยู่ตรงไหนเวลา Debug ถ้าเจอมันซ้อนกันสัก4-5ชั้นก็restructureใหม่เถอะ
34. ด้วยเหตุผลเดียวกัน...อย่าทำnested loopให้มากนัก ไม่ใช่แค่เครื่องจะหน่วงอย่างเดียว ถ้าเจอบั๊กขึ้นมาเราก็คิดตามมันไม่ทันเหมือนกัน
35. อย่าเขียนcodeแบบใช้magic number (คืออยู่ๆ ก็มีตัวเลขนี้โผล่ขึ้นมา เช่น if(type==18) คนอ่านอ่านมันไม่รู้เรื่องหรอก ดีไม่ดีคนเขียนจะมึนเองด้วยซ้ำ...เปลี่ยนไปใช้Enumแทนดีกว่า แบบif(type==Connection.OPEN) อย่ารู้เรื่องกว่ากันเยอะ
36. ถ้าจะเปรียบเทียบstring ให้trim เจ้าwhite spaceออกไปก่อนจะปลอดภัยกว่า
37. คิดให้ละเอียดก่อนเขียนTrigger แล้วเขียนเสร็จแล้วอย่างลืมว่ายังมีมันอยู่ ไม่งั้นเป็นเรื่องแน่
38. เมื่อโปรแกรมเมอร์มาอยู่รวมกันเยอะ แน่นอนมันจะเกิดสิ่งที่เรียกว่ามลพิษทางความซับซ้อน ทางแก้คิดหาproject managerเก่งๆ สักคนมาคุมอีกที
39. คนฉลาดกว่าคอม เพราะฉะนั้นอย่างให้มันคุมเราได้ เราต้องเป็นคนคุมมัน
40. รับฟังผู้อื่นเสมอ แต่อย่าเสียความเป็นตัวของตัวเอง (หมายถึงเวลาโปรแกรมด้วยนะ)

อันนี้แถมท้ายให้...

ปุ่มsaveกดไว้เสมอ ไม่ได้เสียตังค์ ไม่กดบ่อยๆ ไฟดับ แบตหมด เจอerror เกิดblue screenแล้วจะไม่มีใครช่วยได้นะ

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

*