แมวพหลโยธินหลับ
Three Goblin Art
Sade Olutola
AnasAbdin
hello vonnie
styofa doing anything
todays bird
No title available
trying on a metaphor
RMH
he wasn't even looking at me and he found me

roma★

oozey mess

Product Placement
No title available
Peter Solarz
art blog(derogatory)

Discoholic 🪩
Xuebing Du

No title available
we're not kids anymore.

seen from United States

seen from Türkiye

seen from Moldova
seen from Moldova

seen from United States

seen from United States

seen from United States
seen from United States
seen from China

seen from United States
seen from United States

seen from United States
seen from United States
seen from United States
seen from United States
seen from United Kingdom

seen from United States

seen from United States

seen from Türkiye

seen from United States
@chansom
แมวพหลโยธินหลับ
The Beatles T-Shirt :)
Pair Programming ครั้งแรกกับแฟน
วันนี้ได้มีโอกาส pair programming กับพี่ป้อ เลยจะเอาสิ่งที่ได้ในวันนี้มาแชร์ให้อ่านกัน
Sprint นี้ได้ทำ Feature นึงที่มี Logic มองดูเหมือนซับซ้อน เพราะต้องเช็คเงื่อนไขต่างๆก่อนที่จะ Save ข้อมูลได้ ตอนที่ได้รับการ์ดเข้ามาก็งงๆว่าจะเริ่มตรงไหนก่อนดี กังวลไปหมด ได้พี่ป้อนี่แหละบังคับให้ไปถามคนที่รู้ว่า จะทำการ์ดใบนี้ได้สำเร็จต้องมีอะไรบ้าง
โชคดีที่ PO ประจำ Sprint นี้เตรียมเอกสารให้ทีมค่อนข้างละเอียด เตรียม Diagram ให้เห็น Flow การทำงาน แต่ยังเป็นภาพกว้างๆอยู่ แต่พี่ป้อก็สั่งให้เขียน SBE (Specification By Example) จาก Diagram ที่ PO ให้มานั่นแหละ ได้ออกมา 3 Test Case แต่ก็ยังเริ่มไม่ได้อยู่ดี เพราะเอกสารที่ PO เตรียมมาให้ Request ที่จะต้องส่งไป Save มันคืออะไรก็ไม่รู้ ชื่อ Parameter บ้างตัวเป็นชื่อย่อ บางตัวไม่รู้จะเอามาจากไหน (ไม่มี Test Data นั่นเอง)
โชคดีที่มีบ้าน B มานั่งด้วยใน Sprint นี้ เลยตะโกนถามคนที่น่าจะรู้ในส่วนตรงนี้ไป ก็ได้ Test Data มาเรียบร้อย เราได้ Test Case ที่มี Test Rule + Test Data เรียบร้อย สิ่งต่อไปที่จะทำก็ต่อไปเขียนโค้ด Angularjs เพราะปรึกษากับทีมแล้วว่ามันเป็นการ Save ถ้า Dataเราเอาไปใช้ใน Robot มันจะใช้ไม่ได้อีก ก็เลยข้ามไปไม่ยอมเขียน Robot ก่อน แต่โดนพี่ป้อเบรคซะก่อนว่า มันเขียนได้ ให้ลองเลือกมาสัก Test Case แล้วเอามาเขียนซะดีๆ โอเคยอมจร้ายอม
หลังจากนั้นก็เริ่มเขียน Robot Spec ตามที่ต้องการจะให้เป็นเลย เขียนเสร็จก็เริ่มเขียน Angularjs ที่ทำให้ Robot Spec ผ่านเร็วที่สุด ก็ได้โค้ดหน้าตากากๆมาแบบไม่มี Test เลยเพราะ Hard Code เข้าไปไงละ ค่อยๆเขียวไปทีละ Step จน Case สุดท้าย มันทำให้รู้ว่ามันต้องแดงอย่างนี้แหละ เพราะมันไม่ได้ไป Save จริงๆ ทีนี้ก็ได้เวลาไปเขียนโค้ดให้มันไม่ Hard Code เข้าไปแบบนั้น เราก็เริ่มโดยการทำ TDD เขียน Unit Test แล้วก็เขียนโค้ดให้ Test ผ่านเร็วที่สุด และ Run Robot Spec ก็ยังผ่านอยู่ และ Refactor ทำเป็น Loop ไปอย่างนี้จนถึง Case ที่ทำให้รู้ว่าต้องไป Call Api จริงๆ ก็ได้เวลาไปเขียน Go
ภาพประกอบจากหนังสือ http://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627
แล้วที่ผ่านมาไม่ได้ทำแบบนี้หรอ ตอบว่าใช่ เพราะการทำงานในทีมยังทำเป็น Silo เล็กๆ โดยได้การ์ดมาก็แบ่งกันคนนี้ไปเขียน Robot Spec คนนึงไปเขียน Go อีกคนไปเขียน Angular แบ่งงานกันเป็นชิ้นๆ ซึ่งโดยส่วนใหญ่ โค้ด Go จะเสร็จเร็ว โค้ด Angular จะเสร็จช้าที่สุด ส่วน Robot จะไม่เสร็จเลยเพราะรอโค้ด Angular เสร็จก่อน Robot ถึงจะเขียว พอถึงเวลาเอาชิ้นส่วนแต่ละอย่างมาต่อกัน ทำงานไม่ถูกตาม Spec ที่ตกลงกันไว้ เพราะเวลาที่แยกกันไปทำ เราเผลอไปทำคนละ Flow บ้าง เข้าใจ Flow ผิดๆบ้าง ไม่ได้ Pair Programming กัน ส่งผลให้
- งานไม่เสร็จเป็นการ์ดๆ เพราะแต่ละคนก็ไปทำในส่วนที่ตัวเองถนัด
- Bug กระจาย โดยส่วนใหญ่จะเห็นว่าเป็นเป็นสิ่งที่ไม่ได้ตกลงกัน ไม่ได้เขียน SBE ไม่มีใน Spec ก็เกิดจากตอนที่ทำ Sprint Planing ไม่ได้ทำความเข้าใจโจทย์ที่ได้มา แล้วตอนทำก็แบ่งกันทำเป็นส่วนๆอีก
คิดว่าถ้าทำแบบนี้เราจะเร็วขึ้น
- ทีมทำ Pair Programming ความรู้จะกระจายไปทุกๆคน ถือโอกาส Review Code ของคนในทีมด้วย และลายมือโค้ดจะเป็นลายมือทีม ไม่ใช่ลายมือของคนๆเดียว
- แต่ละคนไม่เอาตำแหน่งติดตัว เช่นคนที่เป็น Tester ก็จะไม่ทำหน้าที่ Test อย่างเดียว จะมานั่ง Pair กับ Dev ช่วยกันเขียนSBE, Robot Spec และให้ Dev สอนเขียนโค้ดด้วย
ที่บรรยายมาทั้งหมดต้องการจะบอกว่าเราต้องทำความเข้าใจโจทย์ที่ได้มา ถ้าไม่เข้าใจต่อให้เก่งขนาดไหนก็หาคำตอบไม่ถูก หาได้ก็ไม่ครบ เราต้องเข้าใจ Spec และเลือกมาสัก Flowค่อยๆFocus ไปทีละจุด ทำให้ผ่านไปทีละนิด ไม่รีบร้อน เขียน ATDD, Unit Test สำคัญมาก
เขียน Test แล้วไม่มี Bug จริงหรอ
ความจริงเกี่ยวกับการทำ Test!!!!!
มีโอกาสเสมอที่ Software จะมี Bug
การเขียน Test ไม่ได้พิสูจน์ว่า Softwareทำงานได้ถูกต้อง
เขียน Test หลังจากพัฒนาSoftwareเสร็จแล้ว ไม่ช่วยให้คุณภาพของSoftwareดีขึ้น
Software เกิดจากคน คนมีอารมณ์ความรู้สึก คนมีโอกาสผิดพลาดเสมอ
ดังนั้นเราจะเขียน Test ไปทำไม???
ลดความเสี่ยง เพิ่มความมั่นใจ ในเมื่อเราทำให้ Bug หายไปจากโลกนี้ไม่ได้ เราก็สร้างพื้นที่ปลอดภัยให้กล้าก้าวเดิน
ถ้าบอกว่ามี Bug ต้องบอกได้ว่าเกิดขึ้นที่ไหน จากตรงไหน เกิดอย่างไร
Test ตั้งแต่เนิ่นๆ Test บ่อยๆ Test ต่อเนื่อง
ทำไม Test ถึงสำคัญ???
"คนมีโอกาสผิดพลาดได้เสมอ Test เป็นเพื่อนที่มาช่วยดูว่าจะเกิดข้อผิดพลาดตรงไหน"
Bug เกิดขึ้นได้อย่างไร???
System Design คนที่ออกแบบไม่เก่งจริง ไม่เคยเล่นหรือศึกษาเทคโนโลยีที่เปลี่ยนไป ออกแบบมาผิดคิดว่าระบบคล้ายๆกันน่าจะใช้แบบเดียวกัน มีปัญหาเรื่อง performance
Implementation บังคับให้เจอ Tool หรือภาษาที่ไม่ถนัด แล้วก็มั่วเปิดๆทำตาม Google และ Stack Overflow
Supporting System ชอบลองของที่ไม่คุ้นเคย เขาว่าดีแต่มันอาจจะไม่เหมาะกับงานที่เราทำอยู่
ทีมที่ทำการทดสอบระบบ "กาก" Test ไม่ครบ Test ไม่ครอบคลุม
Evolution ระบบมีการเปลี่ยน Database มีการ Update Version
สรุป เขียน Test กันเถอะ ทำ Automated ด้วยยิ่งดี
ทำไมซอฟต์แวร์ถึงไม่มีคุณภาพ?
คุณภาพ [คุนนะ-] น. ลักษณะที่ดีเด่นของบุคคลหรือสิ่งของ.
เคยเห็นรายการโชว์ในตอนเด็ก ที่จะให้คนอยู่ในตู้ ยืนเรียงกัน 5 คน คนที่1 ออกไปอ่านคำใบ้ แล้วไปสื่อสารให้คนต่อไปโดยห้ามออกเสียง ให้แสดงท่าทางอย่างเดียว แล้วคนที่2 เมื่อเห็นคำใบ้จากคนที่1 ก็ตีความและสื่อสารให้คนที่3 ต่อไปเรื่อยๆ จนคนสุดท้าย คนสุดท้ายมักจะตอบผิดเสมอ เนื่องจากเกิดความผิดพลาดในการสื่อสาร และเกิดจากคนที่ 2 คนที่3 คนที่4 คิดมโน จินตนาการใส่เข้าไปอีก ทำให้สื่งที่คนที่1ต้องการสื่อสารเพี้ยนไปหมด
เปรียบเทียบกับการทำซอฟต์แวร์ ถ้าสมมุติว่าคนที่1คือ ลูกค้าที่จะมาจ้างเราทำระบบร้อยล้าน บริษัทของเราส่งคนที่2 ไปหาลูกค้าเพื่อไปเก็บ requirement แล้วให้คนที่2ทำการวิเคราะห์และเขียน spec ขึ้นมาแล้วส่งไปให้คนที่3 เพื่อนำ spec ไปเขียนโค้ด จนวันสุดท้าย ลูกค้ามาตรวจรับงาน เห็นระบบที่ทำแล้วเงิบ "มันไม่ใช่แบบนี้ อันนี้อยู่ตรงนั้น อันนั้นอยู่ตรงนี้"
ทั้งหมดนี้เกิดขึ้นในทุกๆอาชีพ ทุกๆสาขาวิชา ไม่ใช่เพียงแต่การพัฒนาซอฟต์แวร์ ปัญหาที่เกิดคือเราไม่คุยกัน คุยกันน้อย คุยกันผ่านตัวหนังสือ ทั้งๆที่ทีมเราก็นั่งข้างๆกัน แต่คุยผ่าน Email, Skype, Line, Facebook เพื่อถามงาน ซึ่งมันเป็นไปได้น้อยมากที่จะได้รายละเอียดครบถ้วน เท่ากับการมานั่งพูดคุยกัน
สรุป พยายามลดความห่างระหว่างทีมและลูกค้า ด้วยการคุยกัน แล้วคุณจะได้ซอฟต์แวร์ที่ดีขึ้นมา
Python (First Love)
เคยได้ยินมานานแล้วแต่ไม่มีโอกาสได้ลองเล่นสักที จนไปงาน Global Day of Code Retreat Bangkok 2013 โดยได้ลองเขียน Unit Test กับโจทย์ Game of Life ความรู้สึกคือภาษามันสวยงาม บอกไม่ถูก ดูง่ายๆดีเนอะ (คือยังไม่ได้เจาะลึกลงไป) แต่ตอนนี้อ่านแล้ว รู้สึกเข้าใจ และถ้ามีพื้นฐานมาจากภาษาอื่นๆก็น่าจะทำได้
วันนี้พี่ๆเลยแนะนำให้หัดดู โดยฝึกจาก Python Koans ซึ่งเป็นสื่อการสอน แบบ interactive ซึ่งจะมี Test Case มาให้ แล้วให้เราแก้ไขให้ Test ผ่าน เติมคำในช่องว่าง ลองรัน ดูว่าผ่านยังไปเรื่อยๆ สนุกมากๆขอบอก
สำหรับการเริ่มต้นก่อนจะเล่นต้องไปลง Python ซึ่งมันมี V2, V3แต่เราใช้ Python3 หลังจากนั้นก็ไปโหลดไฟล์มาจาก https://bitbucket.org/gregmalcolm/python_koans
กด Download แล้วทำการแตกไฟล์ .zip
เปิดโฟลเดอร์ใน subl จะเห็นโครงสร้างไฟล์ดังนี้
ในที่นี้เราจะใช้ python3 ก็ cd เข้าไปใน python3 หลังจากนั้นก็สั่ง Run
- ถ้าเป็น Windows ก็ Run ไฟล์ run.bat
- ถ้าเป็น OSx ก็ Run ไฟล์ run.sh
หลังจาก Run เสร็จแล้วบน Terminal ก็จะแสดงผลดังนี้ โดยจุดที่ต้องสังเกตคือ มันสั่งให้ไปแก้ไขโค้ดที่ไฟล์ ตามPath นี้
/Users/iporsut/Desktop/gregmalcolm-python_koans-5e10787a4d8d/python3/koans/about_asserts.py"
บรรทัดที่ 17, ใน test_assert_truth
และฟ้องว่า assertTrue ต้องเป็น True นะมิใช่ False
ไปตามที่มันบอกแล้วแก้ตามที่มันสั่ง Save แล้ว Run อีกรอบ ดูผลว่าเป็นยังไง
แก้ตรง self.assertTrue(False) ไปเป็น self.assertTrue(True) แล้วรันดูอีกรอบมันจะเขียวแล้ว แก้Test ผ่านแล้ว
แต่ก็มีอันใหม่มาให้ลองเล่นไปเรื่อยๆ สอนให้รู้ไปทีละเรื่อง เจ๋งมากๆเลย
ข้อดี
ทำให้ไม่เบื่อในการเรียนรู้ภาษา
ถ้าคนที่เคยเขียนภาษาอื่นมาก่อน จะเรียนรู้ได้เร็วกว่าการหัดจากการอ่านหนังสือ
ทำให้เห็นวิธีการเขียน Test ตั้งแต่แรกของการหัดภาษา
ข้อเสียของ Python Koan โค้ดชุดนี้
ต้องรันใหม่ตลอดๆ
เมื่อสองสามอาทิตย์ที่แล้วได้มีโอกาสเรียน Sai Mixins (CSS Preprocessor) ของพี่เต้ย ซึ่งเป็น Extension สำหรับ LESS/SASS Framework
ประโยชน์คือ มันช่วยทำอะไรหลายๆอย่างที่ CSS ธรรมดาทำไม่ได้ เช่น การสร้างตัวแปร การสร้าง Mixins ซึ่งทำให้ลดความซ้ำซ้อนของโค้ดลง และโค้ดอ่านง่ายขึ้น โดยการเขียนเป็นไฟล์ .less , .sass ทำผ่านการ compile จึงได้ไฟล์ .css ไปใช้
เริ่มจากขั้นตอนแรกเลยคือ ดาว์นโหลด Sai จาก ที่นี่
แล้วก็จะได้โฟลเดอร์ชื่อ sai-master ข้างในก็จะมีองค์ประกอบดังนี้
sai.less คือไฟล์ที่มีคำสั่งเกี่ยงกับ Component ต่างๆมาให้
sai_test.less คือไฟล์ตัวอย่าง
ขั้นตอนที่สอง ไปดาน์วโหลดตัว Compile LESS ให้เป็น CSS โดยผู้เขียนได้ใช้โปรแกรมฟรีคือ http://incident57.com/less/
สร้างไฟล์ style ของเราขึ้นมาชื่อว่า style.less และ Set CSS Output Path ไปที่ๆเราต้องการ
จากนั้นก็เขียน Style Sheet ในไฟล์ที่เราสร้าง "style.less" หลังจากนั้นพอเรา save แล้ว โปรแกรม LESS มันจะ Compile ไฟล์ให้และแปลงโค้ดเป็น css ที่สามารถนำไปใช้จริง
หลังจากโปรแกรมคอมไพล์แล้ว
อันนี้เป็นแค่ตัวอย่างง่ายๆนะ มันมีอะไรให้ลองเล่นอีกเยอะเลย มันจะช่วยให้เรามองเป็น Block แล้วลักษณะการเขียน CSS ก็จะเหมือนการเขียนโปรแกรมที่เป็นฟังก์ชัน รับค่า มีตัวแปร มันฟินตรงนี้แหละคร้าบบ
วัฒนธรรมอย่างไรที่ต้องการ ก็สร้างเอง
Session ที่ชอบที่สุด เพราะฟังรู้เรื่องที่สุดของวันนี้คือ "Building Agile Culture for Any Scale" โดยพี่ Amp และ พี่ Pam จับใจความสำคัญและเข้าใจดังนี้
Culture สำคัญกว่า Process ที่กำลังดังๆ ณ ตอนนี้ หลายคนร้องเรียกหา Agile มันดี มันต้องทำนะ วิ่งเรียนรู้และหา แต่วัฒนธรรมขององค์กรตัวเองไม่เปิดใจ ไม่พร้อมที่จะทำ ก็เปล่าประโยชน์
จากรูปคือการปลูกต้นไม้ที่ต้องการให้มันเป็นกวาง ก็เลยวางโครงเอาไว้เป็นรูปกวาง พอต้นไม้มันเป็นไม้เลื้อย มันก็จะเกาะๆตามโครงไป ทำให้ได้ต้นไม้รูปกวางตามที่ต้องการ
ถ้าเปรียบกับ Culture ในบริบทขององค์กรก็คือ การสร้างวัฒนธรรมที่ต้องการ วัฒนธรรมที่ทุกคนเห็นตรงกันและมองว่าเป็นสิ่งที่จะช่วยให้องค์กรดีขึ้น เช่นการมาทำงานเช้า มีอะไรพูดคุยกันตรงๆ คุยกันด้วยเหตุผล ไม่นินทากันลับหลัง พอเด็กใหม่หรือเพื่อนทำงานคนใหม่ เข้ามาในองค์กร เขาก็จะได้รับวัฒนธรรมที่เราสร้างกันไว้เองโดยอัตโนมัติ สรุป "Culture เป็นตัวกำหนดพฤติกรรมของมนุษย์"
Rule กฏระเบียบ ข้อบังคับ ข้อตกลงที่ตั้งขึ้นมาเพื่อให้คนกลุ่มหนึ่งทำตาม ในรูปเป็นต้นไม้ที่โตในกระถางเล็กๆใบหนึ่ง แล้วมีกระถางอีกใบครอบข้างบน พอต้นไม้เริ่มเติบโตก็ไม่มีที่ไป เบียดกัน จนหมุดทะลุดินไปเลย ผู้เขียนต้องการจะสื่อว่า ต้นไม้ที่โตในกระถางแบบนี้จะค่อนข้างรู้สึกอึดอัด เพราะโดนบังคับ อันนั้นก็ทำไม่ได้ อันนี้ก็ทำไม่ได้ ผลลัพธ์ที่เกิดจะมีสองแบบคือ คนที่เขาพอรับได้ เขาก็ยังจะอยู่ในองค์กรต่อไป แต่อาจจะอยู่แบบไม่มีความสุข หรือกรณีที่สองคือ ทนไม่ไหวแล้ว ลาออกเลยดีกว่า เอาหน้ามุดดินหนีไป
จากทั้งหมดที่กล่าวมา จะเห็นว่าการสร้างวัฒนธรรมสำคัญมาก และสิ่งแรกที่ผู้เขียนจะพยายามเอาไปปรับใช้คือ
- ไม่มีลูกน้อง ไม่มีหัวหน้า พวกเราทุกคนคือทีม
- ไม่นินทากันลับหลัง มีอะไรคุยกันตรงๆ และ Focus ที่ Goal ของทีม
ถ้าทีมมีลักษณะดังต่อไปนี้ ทีมของคุณไม่ใช่ Agile
วันนี้ได้มีโอกาสไปงาน Agile Tour Bangkok 2013 และได้เข้าฟังทั้งหมด 7 Session
Your Team Is Not Agile If.......
The 7 Habits of Effective Agile
Building high performance culture
Necessary but not sufficient, lesson learned from success and failed agile executions
Building Agile Culture for Any Scale
When I Applied Agile for Thailand Government Software
Panel Discussion
ตอนนี้ก็ยังไม่เคยทำงานในทีมที่ใช้ Agile จริงๆ แต่อยากศึกษาดูไว้ มองหลายๆมุม หลายๆวิธีการ และถ้าได้ทำทีมที่บอกในงานว่า มีทีมแค่ 2 คน จะได้เอาบางส่วนที่ตรงกับลักษณะของคู่เราไปปรับใช้
และมี Session ที่น่าสนใจที่จะนำมาเขียนบล็อกวันนี้ก่อนคือ "Your team is not agile if..."
ถ้าทีมมีลักษณะดังต่อไปนี้ ทีมของคุณไม่ใช่ Agile
กลัวความผิดพลาด ไม่กล้าจะทำอะไร กลัวมันผิด กลัวโดนด่า
ไม่ค่อยอยากจะเปลี่ยนอะไร อยากอยู่ใน Comfort Zone ชีวิตปลอดภัยแล้ว
ขาดแรงบันดาลใจในการทำงาน ไม่รู้ว่าจะทำไปเพื่อใคร ดียังไง มีคุณค่ามากแค่ไหนไอ้สิ่งที่ทำอยู่เนี่ย
ไปนับความสำเร็จจากจำนวนงานที่ทำเสร็จ
ทำงานภายใต้ความกดดัน ความเครียด ผลจากงานก็จะไม่ดี
ให้ความสำคัญหรือแสดงความยินดี กับคนที่เป็น Hero เกินไป ทำให้คนในทีมรู้สึกไม่มีคุณค่า
ไม่สามารถดูแลงานภายในด้วยกันเองได้ ถ้าขาดคนสำคัญไปก็ทำอะไรกันไม่ได้เลย
ขาดการมองภาพรวม
สิ่งที่ควรทำ
อย่ากล่าวโทษคนอื่น ควรทำ Environment ให้น่าอยู่ รู้สึกไว้ใจได้
ควรจะใช้ตัวชี้วัดต่างๆ ให้ถูกต้อง เหมาะสมกับงาน
ยินดีกับความสำเร็จทั้งของตนเอง และของทีม ชื่นชมตัวเองได้ และก็ต้องยอมรับในบางครั้งถ้าทำผิดได้เช่นกัน
ให้ชักชวนเชื้อเชิญคนอื่นให้มาทำ Agile ด้วยวิธีการเป็นมิตร อธิบายเหตุผลว่ามันจะดีต่อเราต่อทีมยังไง ไม่ให้บังคับ
พื้นฐานการออกแบบ Website เบื้องต้น ตอน Typeface Classification (Typography)
วันนี้ผู้เขียนได้ไปเรียน คอร์สออนไลน์ fundamentals-of-design ของ code school เลยเอามาแบ่งปันกันค่ะ
"Content is King" Designer มีหน้าที่สื่อสารเนื้อหา ใจความสำคัญออกไปให้กับผู้รับสาร ไม่ใช่เน้นที่ความสวยงามเพียงอย่างเดียว
องค์ประกอบที่เราต้องคำนึงถึงในการออกแบบ
กลุ่มเป้าหมายเรา : อายุเท่าไหร่ เชื้อชาติ สัญชาติ เพศ
ความรู้สึกที่ต้องการสื่อสาร : เป็นทางการ เป็นกันเอง หรือสยองขวัญ
วัตถุประสงค์ : เพื่อส่งข้อมูลข่าวสาร ความรู้ หรือความบันเทิง
ก่อนที่เราจะสื่อสารเนื้อหาออกไป เราก็ต้องทำให้เนื้อหามีความน่าสนใจด้วย Typography, Color, Layout ฯลฯ แต่โพสนี้เราจะมาเรียนรู้เรื่อง Typography กันก่อนนะค่ะ
ศิลปะของตัวอักษร (Typography)
- ควรจะมี Style Guide ของเราเอง ว่า Headline, Sub-Head , Navigation, Body, Footer เราจะใช้ Font อะไร ขนาดเท่าไหร่ เพื่อให้ใช้อ้างอิงกับทุกๆหน้าตอนทำงาน
Classifications of Type (3 แบบ)
1. Serif เป็น Class ที่มีติ่ง
Humanist, Transitional, Modern, Egyptian เราจะเรียกมันว่า "Style"
2. San-Serif เป็น Class ที่ไม่มีติ่ง
Humanist, Transitional, Geometric เราจะเรียกมันว่า "Style" เช่นกัน
3. Script (Hand Writing) เป็น Class ที่ไม่เหมาะจะเอามาใช้กับสื่อสิ่งพิมพ์ อ่านยาก เพราะเป็นตัวเขียน แต่ก็เอามาใช้บนเว็บ เพื่อดึงดูดความสนใจได้
ไม่แนะนำให้ใช้ Font "Comic Sans" ในทุกๆกรณี
หลังจากรู้จัก Class ของ Font ไปแล้ว เรามาดูกันว่า Font ไหนในเครื่องเรา เหมาะกับงานประเภทใดบ้าง ผู้เขียนเลยทำตารางสรุป Font Class "Serif" มาให้ดูกันค่ะ
และตารางสรุป Font Class "San Serif"
ต่อไป ถ้าเราต้องการที่จะออกแบบโดยใช้ Font หลายๆแบบในหน้าเดียว มีวิธีการดังนี้
1. ลองใช้ Serif ในส่วนที่เป็น Heading & Sub-Heading , ใช้ San-Serif ในส่วนที่เป็น Body เช่น
2. อย่าใช้ 2 Font ที่มี Style เดียวกัน แบบที่ไม่ควรทำ เช่น
จากตัวอย่างนี้ ใช้ Style เดียวกันคือ "Humanist" ทำให้ดูแล้วไม่ค่อยแตกต่างกัน
3. อย่าใช้ 2 Font ที่มี Class เดียวกัน เช่น
จากตัวอย่างนี้จะเห็นได้ว่า เขาใช้ Class เดียวกันคือ "Serif" ทำให้ดูแล้วไม่ค่อยต่างกันระหว่าง Head กับ Sub-Head
4. ถ้าต้องการ Mix กันระหว่าง Class "Serif" กับ "San-Serif" ควรจะใช้ Font ที่มี Style เดียวกัน เช่น
5. ควรจะใช้ Font ให้คงที่ Head ใช้ Font อะไรก็ควรใช้ให้เหมือนกันหมดทั้งหน้า, Body ใช้ Font อะไรก็ควรใช้ให้เหมือนกันทั้งหน้า
6. ถ้า Font ไหนมีลิขสิทธิ์ก็ควรจะทำให้ถูกต้อง แต่ดีที่สุดคือ Font ฟรี
ผู้เขียนหมดพลังงานแล้ว รอติดตามเรื่องต่อไป (Size, Leading, Weights) พรุ่งนี้ค่ะ
เครื่องมือดู Outline ของเว็บ ด้วย Lynx Browser
หลังจากที่ได้พยายามเปิดดูเว็บชาวบ้าน เพื่อดูสไตล์การเขียน HTML การจัด Outline ไปจนถึงปิด Style Sheet เพื่อดูว่าเว็บเหล่านั้นอ่านออกหรือไม่ iPor (แฟน) ได้แนะนำ Web Browser เก่าแก่ตัวนึงที่อยู่ใน Text Mode ตัวนึงชื่อว่า Lynx
พระเจ้าจอร์ชมันยอดมาก นอกจากมันจะสามารถเปิดดูเว็บได้ เหมือนมันจะอ้างอิงการแสดงผลตาม Outline ให้ด้วยนะ เราต้องการพอดีเลย เลยทดลองเปิดดูเว็บที่คิดว่าเจ๋งๆ outline เทพๆอย่าง thaicss.com
ใครมี Linux มาลองเล่นกันดูนะค่ะ
1. เริ่มต้นด้วยการเปิด Command line ขึ้นมา แล้วพิมพ์คำสั่ง
apt-get install lynx
2. เมื่อติดตั้งเสร็จ ก็เริ่มใช้งานด้วยคำสั่ง
lynx
หน้าตาของมันจะประมาณนี้
3. เนื่องจากเพิ่งเลยเล่น lynx คำสั่งที่รู้มีเพียงคำสั่งเดียวคือ กด shift + G เพื่อไปพิมพ์ url ของเว็บที่ต้องการไป
ลองเปลี่ยนจาก lynx.isc.org ไปเป็น thaicss.com ดูนะ
4. หลังจากนั้นมันก็จะไปเปิดเว็บที่เราต้องการ และแสดงผลดังนี้
พี่พรแห่ง thaicss.com เขาเขียนเว็บได้ดีมากๆ อ่านออก ทั้งๆที่ใช้ Browser เก่าๆ หรือปิด Style Sheet ไป ข้อมูลของเว็บก็ยังเป็นสัดส่วน ที่ทำให้รู้สึกว่าถึงไม่มี Style Sheet ก็ยังใช้งานได้อยู่ อ่านข้อมูลได้ครบถ้วน
ตอนนี้ผู้เขียนก็กำลังศึกษาโค้ด Pattern การเขียนโดยอ้างอิงจากเว็บนี้เลย แล้วอย่าลืมไปติดตั้ง lynx และลองเข้าเว็บโปรดของเราดูนะค่ะ ว่าการแสดงผลเป็นอย่างไรบ้าง :)
12 ข้อที่เด็ก (Developer) จบใหม่ควรทำความรู้จัก
ด้วยวาสนาหรือชะตา(กรรม)พัดพามาให้เรียน "วิศวกรรมคอมพิวเตอร์" มิหนำซ้ำยังทำให้หลงใหลได้ปลื้มกับการเขียนโค้ด อีกไม่กี่วันก็จะจบแล้ว ลองหาข้อมูลเตรียมตัวเป็น Developer ที่ดีสักหน่อย จะได้เอามาปรับใช้ ถือว่าเป็นศิริมงคลในชีวิตในการเริ่มทำงาน
ค้นไปเจอสไลด์ที่มีชื่อเรื่องว่า "12 Things Every Programmer Should Know" เห็นว่าน่าสนใจและน่าจะเป็นประโยชน์สำหรับเด็กจบใหม่อย่างเราๆ เลยนำมาแปลเป็นไทย เท่าที่จะพอเข้าใจได้ดังนี้
1. Be Passionate มีความรักในสิ่งที่กำลังทำ รักในสิ่งกำลังจะสร้าง ชอบที่จะทำให้ดีและชอบที่จะปรับปรุงให้ดีกว่าที่ผ่านมา
"Programmer are a subset of creator have the responsibility to shape the new world " โปรแกรมเมอร์เป็นส่วนหนึ่งของผู้สร้าง ซึ่งผู้สร้างจะมีภาระที่ต้องปรับปรุง เปลี่ยนแปลงโลกในอนาคต @steveklabnik and @jodufyr กล่าว
2. Love Your Codes รักโค้ดที่คุณเขียนมันขึ้นมาเอง การที่จะรักหรือชอบโค้ดที่เขียนขึ้นมานั้น โค้ดนั้นมันต้องอ่านรู้เรื่อง สะอาดตา เราถึงจะรักจะชอบ เพราะฉะนั้นก็พยายามเขียนให้มนุษย์ด้วยกันเองอ่านรู้เรื่อง ไม่ใช่เขียนให้ machine อ่านได้อย่างเดียว
3. Version Control อย่าง Git หรือ Mercurial ใช้เพื่อ Backup โค้ดของเรา เวลาเครื่องพังจะได้สบายใจว่าโค้ดไม่หาย, เวลาทำงานกันเป็นทีมหลายๆคน ก็สามารถจะ Track ได้ว่าใครเปลี่ยนแปลงอะไร เปลี่ยนตรงไหน เปปลี่ยนเมื่อไหร่ ไม่ต้องมานั่งทะเลาะกัน ใครลบโค้ดตรูทิ้งววะ เมื่อวานไม่ Error วันนี้ Error ได้ไง
4. Read Codes เขาบอกว่าจะเป็นนักเขียนที่ดีได้ก็ต้องเป็นนักอ่านที่ดีก่อน โปรแกรมเมอร์ก็เช่นกัน พยายามอ่านและ Note เทคคนิคดีๆที่ช่วยให้ชีวิตง่ายขึ้นและเก็บเอาไว้ใช้
5. Practice, Practice and Practice ฝึกหัด ฝึกฝน ฝึกซ้อม กับแบบฝึกหัดที่เล็กๆง่ายๆ แบบฝึกหัดที่ไม่ได้เกี่ยวกับงานที่ทำอยู่ประจำ โจทย์เกมส์สนุกๆก็ได้ ทำได้เท่าที่มีความสามารถ ไม่ต้องกดดันตัวเอง ยกตัวอย่างเช่นการทำ CodeKata, Pair Programming กับเพื่อนๆก็ได้
อย่างเช่นในภาพเป็นการทำ CodeKata ก่อนอาบน้ำ โจทย์เกี่ยวกับการทำโปรแกรม Todo ให้สามารถ Add item และแสดง item ที่ Add ออกมา
6. Refactoring ปรับปรุงคุณภาพโค้ดของเราให้ง่ายต่อการเข้าใจ ง่ายต่อการ maintain และการต่อยอด แต่จะต้องไม่ไปเปลี่ยนแปลงพฤติกรรมการทำงานของโค้ดนะค่ะ
"Always check a module in cleaner than when you checked it out" Uncle Bob
7. Follow Patterns and Best Practices พยายามติดตามแบบอย่างและกรณีศึกษาที่ดีๆ
Object Oriented Design Principles
SOLID
GRASP
DRY
KISS
Don't Tell Us
Design Patterns
8. ทำ TDD/BDD
Tests คือข้อกำหนดว่า ระบบมันจะทำอะไร
Tests เปรียบเสมือนตัวแทนของผู้ใช้เรา เหมือนกับเป็นผู้ใช้ระบบเราคนแรก
TDD : เขียน Test ให้ Fail แล้วเขียนโค้ดให้ Test ผ่าน หลังจากนั้นทำการ Refactoring ปรับปรุงโค้ดให้ดีขึ้น ส่วนตัวคิดว่ามันน่าจะเป็นวิธีการพัฒนา Software ที่สั้นที่สุดแล้ว
BDD : การพัฒนาแบบขับเคลื่อนด้วยพฤติกรรม (Behavior Driven Development)
9. Automation ทำให้งานที่ต้องทำมือเป็นแบบอัตโนมัติซะ อย่างเช่นจะทดสอบระบบที่มี Form เยอะๆก็มานั่งกรอกทีละ feild ไปเรื่อยๆ หมดกันอนาคต ของแบบนี้มนุษย์อย่างเราไม่จำเป็นต้องทำ ปล่อยให้เป็นหน้าที่ของหุ่นยนต์ ให้มันทำ มันไม่รู้จักคำว่าเหนื่อยไง แต่เราเป็นมนุษย์ เรามีหัวใจ
ตอนนี้กำลังศึกษาการทำ Automate Testing ด้วย Cucumber และ Capybara เป็นเครื่องมือที่ใช้ในการทำงานแบบอัตโนมัติ โดย Script ที่ใช้ในการ ทดสอบอยู่ในรูปแบบของคำอธิบายที่สามารถเข้าใจได้ง่าย ถูกสร้างมาจากภาษา Ruby แต่เราสามารถใช้ Cucumber ทดสอบโปรแกรมที่สร้างจาก ภาษาอื่นๆ ได้เช่น Java, C# และ Python คนที่จะใช้ Cucumber ได้นั้นจำเป็นต้องมีความรู้ในการเขียน โปรแกรมภาษา Ruby อยู่เล็กน้อย แต่ถึงแม้จะไม่เคยเขียนภาษา Ruby มาก่อน ก็สามารถหัดใช้ Cucumber ได้อย่างไม่ยาก เพราะตัวภาษา Ruby เองนั้นก็อ่านง่ายและเขียนเพียงสั้นๆ
Command line เนี่ยแหละ ช่วยเราได้ เมื่อก่อนเราเองเคยพูดว่า อะไรนี่หน้าจอดำๆ ไม่เห็นจะมีอะไรให้กดเลย อย่ากลัวที่จะหัดใช้มัน มีประโยชน์เยอะ เคยใช้เปลี่ยนชื่อไฟล์หลายๆร้อยไฟล์ด้วยคำสั่งเดียว เอาเวลาไปทำอย่างอื่นสบายๆ
10. Understand Your Domain
เข้าใจเรื่องหลักที่เราจะไปแก้ปัญหา เช่นจะทำโปรแกรมบัญชี ก็ต้องเข้าใจ ระบบบัญชี ตรงระบบบัญชีเนี่ยแหละคือ Domain ของเรื่องนี้ ส่วนเรื่อง เทคโนโลยี เรื่องภาษามันเปลี่ยนอยู่ตลอดอยู่แล้ว แต่โจทย์เรายังเหมือนเดิม เข้าใจโดเมนมันให้ดีๆ แค่นั้น
"Domain มันไม่ล้าสมัย เหมือนกับ technology ที่พยายามมาแก้ปัญหามัน"
"Your can't creatively help a business until you know how it works." จะแก้ปัญหาอะไรได้ถ้ายังไม่เข้าใจการทำงานของมัน Chad Fowler กล่าว
11. Continuous Learning คุณจำเป็นต้องเรียนรู้อยู่เสมอ เพื่อทำให้คงอยู่ในวงการนี้ได้ พยายามอ่านหนังสือ อ่านบทความตาม Blog ที่เป็นทั้งภาษาไทยและอังกฤษ ความรู้เยอะแยะมากมายบนด้วยพี่ Google เพื่อเป็นการพัฒนาทักษะดังการฝนมีดให้แหลมคมอยู่เสมอ
12. Participate in Communities มีส่วนร่วมกับคนในวงการ เพื่อนเรียนรู้วิธีคิด กระบวนการ เทคนิคจากพี่ๆ หรือแม้แต่การสอนคนอื่นก็เป็นการเรียนรู้ที่ดีเช่นกัน พยายามพูดในสิ่งที่คิดออกไป ถูกหรือผิดไม่ต้องกลัว ถ้าผิดพี่ๆเค้าก็จะแนะนำได้ถูกจุด ถ้าถูกก็จะได้เป็นการแบ่งปันความรู้ไปด้วย เข้าร่วมกิจกรรมตามที่เราสนใจ เช่นกิจกรรม UX Academy, Geek Academy, Agile Tour Bangkok 2012 ฯลฯ
"สุดท้ายผู้เขียนต้องขอบคุณพี่ๆทุกคนที่ แบ่งปันความรู้ ชี้แนะแนวทาง โอกาสประสบการณ์ทุกอย่าง และหนูสัญญาว่ามีโอกาสก็จะแบ่งปันสิ่งที่ได้เรียนรู้มาให้คนอื่นๆ หรือน้องๆรุ่นหลังๆเช่นกัน"
มาเข้าใจ Outline Algorithm ของ HTML ฉบับง่ายๆ กันเถอะ
การแบ่ง Sectionใน HTML
ทุกเนื้อหาของเว็บ จะต้องอยู่ภายใต้ section ใด section หนึ่งซึ่งอย่างน้อยต้องอยู่ภายใน body ที่ถือว่าเป็น section root และเราสามารถสร้าง section ซ้อนกันได้ โดยอาจจะเกิดจากการใช้ tag ในกลุ่ม <h1> ถึง <h6> ที่จะทำให้เกิด section เองโดยปริยาย หรือกำหนดขอบเขตของ section ให้ชัดเจนโดยใช้ tag เหล่านี้ <body>, <section>, <article>, <aside>, <footer>, <header>, และ <nav>
Explicitly defined sections : <body>, <section>, <article>, <aside>, <footer>, <header>, และ <nav>
Note: แต่ละ Section สามารถที่จะมี ลำดับชั้น heading ของตัวเองได้
จากโค้ดข้างต้นจะเห็นได้ว่า section ตัวแรก มี 3 section ย่อย และจะได้ outline ดังนี้
ประโยชน์ของโปรตีน
1. ประโยชน์ต่อเซลล์ผิวหนัง
2. ประโยชน์ต่อกล้ามเนื้อ
3. ประโยชน์ต่อการฟื้นตัวของร่างกายและระบบภูมิต้านทาน
Implicitly Sectioning <h1> <h2> <h3> <h4> <h5> <h6>
ตามที่เข้าใจคือ ถ้าไม่มีการใช้ <section> ครอบ แล้ว Heading พวกนี้มันจะทำ section ให้เองโดยปริยาย โดยให้ h1 มีความสำคัญสูงสุด h6 ความสำคัญต่ำสุด
แบบที่ 1 :ในตัวอย่างนี้ ใช้ <h1> ซึ่งมีระดับ Lavel เท่ากัน มันก็จะมองเป็นระดับเดียวกัน ความสำคัญเท่ากัน ถ้าเราเผลอไปใช้ ความหมายของบทความก็จะเปลี่ยนไปทันที มันจะมองว่า ประโยชน์ต่อเซลล์ผิวหนังไม่ได้เป็นหัวข้อย่อยในประโยชน์ของโปรตีน
Outline :
ประโยชน์ของโปรตีน
2. ประโยชน์ต่อเซลล์ผิวหนัง
3. ประโยชน์ต่อกล้ามเนื้อ
4. ประโยชน์ต่อการฟื้นตัวของร่างกายและระบบภูมิต้านทาน
แบบที่ 2 : จะใช้ Heading ที่มีความสำคัญตามลำดับ
Outline:
1.ประโยชน์ของโปรตีน
1. ประโยชน์ต่อเซลล์ผิวหนัง
จะเห็นได้ว่ามันสามารถแบ่ง section ให้เราได้เองเลย แต่ต้องระวัง ถ้ามีการใช้ Heading Content อย่างไม่ระวัง อาจจะทำให้ความหมายของบทความเพี้ยนไปได้
ข้อมูลเรื่องประโยชน์ของโปรตีนอ้างอิงจาก http://www.thaifoodworld.com/%E0%B8%AD%E0%B8%B2%E0%B8%AB%E0%B8%B2%E0%B8%A3%E0%B8%AB%E0%B8%A5%E0%B8%B1%E0%B8%815%E0%B8%AB%E0%B8%A1%E0%B8%B9%E0%B9%88/
สร้าง Form อย่างไรให้ User ใช้ง่ายขึ้น
หลังจากที่ได้ไปเรียน HTML & CSS อย่างถูกต้องกับพี่พร แห่ง ThaiCSS.com มาแล้ว วันนี้เลยอย่างจะนำเสนอหัวข้อที่เข้าใจง่ายที่สุดก่อนหัวข้อนึงคือ การสร้างฟอร์ม แต่มีข้อจำกัดบางอย่าง แสดงผลได้บน iOS เท่านั้น Android หมดสิทธิ์
ลองใช้ iPhone เข้าไปที่ url นี้ดูค่ะ http://thaicss.com/lessons/input.html
ใจความสำคัญ 4 อย่างในการสร้าง Form คือ
1. Label and For ต้องมี
<label for="search"></label> <input type="search" id="search" placeholder="คำค้น" />
2. Input Type
<input type="search" id="q" placeholder="คำค้น" />
<input type="text" id="main-text" placeholder="Name" value="" />
<input type="url" id="url" placeholder="http://www.example.com" /> ใช้ type = url เพื่อเวลาเรียก keybord ก็จะได้ keyboard ที่มี .com ติดมา
<input type="email" id="email" placeholder="[email protected]" /> ใช้ type = email เพื่อเวลาเรียก keyboard ที่มี @ ติดมาด้วย
3. Patterns
<input type="text" id="zipcode" pattern="[0-9]*" placeholder="10310" />
<input type="tel" id="tel" placeholder="0834......" pattern="[0-9]{10}" required /> แล้วเขียน pattern เพื่อเรียก แป้นหมายเลขสำหรับการโทรศัพท์เท่านั้น
4. Placeholder
<input type="email" id="email" placeholder="[email protected]" />
ที่ชอบคือ มันมีประโยชน์สำหรับ User คือ ฟอร์มๆนั้นมันต้องกรอกแค่ตัวเลข จะต้องมานั่งเสียเวลาเปลี่ยนคีย์บอร์ดทำไม ลำพังคีย์บอร์ดมันก็เล็กๆอยู่แล้ว
เรียน TDD ด้วย Angular
Test-driven development (TDD)
T = Test เขียน Test ไม่เกิน 30 วินาที
C = Code เขียนโค้ดให้ Test ผ่าน 30 วินาที
D = Refatoring ปรับเปลี่ยน โยกย้ายให้โค้ดอ่านรู้เรื่อง เข้าใจง่าย
โดยครั้งนี้ได้ทดลองทำโปรแกรม Todo โดยใช้ Angular.js เริ่มจากกระบวนการเขียน Test ดังนี้
เริ่มจากการเขียน Test ง่ายๆว่า ถ้าเราเพิ่ม item ไป 1 ตัว แล้วในกล่องๆนั้นต้องมีของแค่ 1 ตัว
หลังจากนั้น Karma (Test Runner) ก็วิ่งมาดูและรัน Test ของเราให้และตะโกนบอกว่า
Karma : คุณยังไม่มี Method ชื่อว่า "addItem" เลยครับ กรุณาสร้าง
หลังจาก Karma มันบอกเราก็ต้องรีบไปสร้าง method "addItem" ตามความต้องการของมันนะค่ะ ไปที่ไฟล์ todo.js
สร้างเสร็จแล้วกลับไปดูที่ Console ว่ามันบ่นอะไรอีก
Karma : ไม่มี method ชื่อ "getLength" กรุณาสร้างมันขึ้นมา ไม่งั้นผมไม่ให้ผ่าน
เรา : โอเค คุณต้องการใช่มั้ย เราจะจัดให้
เสร็จแล้วไปดูกันว่ามันต้องการอะไรอีก
Karma : มันไม่มีค่านะพี่ ที่พี่คาดหวังไว้นะ ที่จะเอามาเทียบกับ 1 คุณพี่กรุณาไปหาค่ามาเทียบกับ 1 ซะดีๆ
เรา : ได้พี่จัดให้อย่างสาสมใจ return 1; ให้มันไปโลด
Karma : ขอแสดงความยินดี คุณประสบความสำเร็จแล้ว :)
อันนี้แค่ Test เดียวเองนะ ดูยุ่งๆเยอะๆ แต่นี่แหละ กระบวนการ TDD ที่เราเข้าใจคือ เขียน Unit Test เล็กๆที่มัน Fail แล้วไปแก้โค้ดให้ Test ผ่าน (แก้เท่าที่จำเป็น) พอ Test ผ่านแล้วทำการปรับปรุงให้โค้ดดีขึ้น เรื่องตัวแปร รูปแบบการเขียน เสร็จแล้วก็วนกลับไปเขียน Test อีก เป็นวงจรชีวิต
ขอบคุณพี่ Chokchai Phatharamalai ที่ช่วยทำให้เข้าใจการทำ TDD และสอน Angular.js ด้วยค่ะ
สำหรับใครที่สนใจต้องเตรียมตัวดังนี้
1.โหลด Karma (เดี๋ยวเขียน Blog วิธีการลงให้)
2. Clone โปรเจคนี้มา https://github.com/juacompe/tdd_angular_v2 ลองเล่นดูเอง
3. ลองทำตามข้าพเจ้า
ข้องสังเกตุจาก Scrum Master ของเรา
หลังจากพี่ Scrum Master ออกมาพูดที่ได้จากการสังเกตุตอนที่แต่ละทีมทำงาน และจดใส่กระดาษเล็กๆไว้ หนูก็แอบไปขอถ่ายข้อมูลตรงนั้นเพื่อเก็บมาเขียนบล็อกไว้เตือนความจำและแชร์ คิดว่าข้อมูลตรงนี้มีประโยชน์มากเลยทีเดียว ในการทำงานครั้งต่อไปหนูจะได้เอาข้อมูลตรงนี้ไปปรับปรุงตัวเอง ขอบคุณพี่รุ่ง Pitsanu Swangpheaw (Scrum Master) มา ณ ที่นี้ด้วยค่ะ
1. Out of Sync พี่เขาบอกว่าตอนที่ออกไป Scrum of Scrum ตัวแทนไม่เอาข้อมูลที่เปลี่ยนแปลงมาบอกกับทีม ทำให้เกิดการทำงานซ้อนกันหลายงาน ซึ่งอันนี้ผู้เขียนผิดเอง เนื่องจาก เคยเป็นตัวแทนออกไปทำ Scrum of Scrum แล้วมีอีกกลุ่มจะทำงานนั้นแต่ไม่ได้ไปเลื่อนการ์ด การ์ดยังอยู่ที่ Todo ทำให้กลุ่ม Kitty มาหยิบไปทำจนเสร็จ ปรากฎว่า กลุ่ม Pikachu ก็ทำ :'(
2. Technical Debt เป็นหนี้ทางเทคโนโลยี การที่เรายอมทำงานให้ใช้ๆได้ไปก่อนโดยไม่ได้สนใจคุณภาพ แล้วเมื่อวันนึงที่เราต้องกลับมาแก้ไขหรือปรับเปลี่ยนอะไรบางอย่าง เราจะทำได้ยากมา
3. กระจายความรู้หรือยัง?? อาจจะเป็นเพราะว่าทีมเลือกใช้เทคโนโลยีที่ใหม่ แล้วมีคนที่ใช้เป็นไม่กี่คน คนที่ทำเป็นก็ต้องทำ อันนี้แนะนำว่าควรจะมีคอร์สที่สอนให้กับทุกคนนทีมเลย จะได้ตามไปพร้อมๆกัน
4. Integration เวลาที่จะต้องเอาโค้ดมาประกอบร่างกันให้มันใช้ได้ ให้เอามารวมได้เลยตามเห็นสมควรไม่ต้องรอ
5. Communication คุยกันข้ามทีมบ่อยๆได้เลย ถ้าคุยบ่อยเรื่องเดิมซ้ำๆ น่าจะมีความผิดปกติของการสื่อสารเกิดขึ้น
6. การจด feedback หนูเป็นคนนึงในทีมที่ไม่ค่อยชอบพกปากกา กับกระดาษจด เวลาที่ไปคุยกับ PO หรือคุยกันในทีม มีอะไรก็พูดไปลอยๆ ไม่ได้จด จำอย่างเดียวแล้วก็ลืม
7. คนดูมากกว่าทำ โดนอีกละ หนูก็ทำพวก HTML CSS ได้เท่านั้น พอเสร็จก็ไปนุ่งดูพี่เค้าทำ API ดูอย่างเดียวจริงๆ
8. คุยเกิน Time Box แล้วได้ประโยชน์อะไรหรือเปล่า ในทีมหนูจะ Daily Meeting แค่แปบเดียวเอง ประมาณ 5 นาทีได้ แต่เค้าบอกว่าประมาณ 10-15 นาทีกำลังดี แล้วในเวลาที่ประชุม ควรจะพูดแค่ 3 เรื่องคือ เมื่อวานทำอะไร วันนี้จะทำอะไร มีปัญหาอะไร โดยเวลาพูดต้องรายงาน สบตากับทุกๆคน อย่ารายงานให้ผู้ที่ดูอาวุโส แล้วหลังจากคุยเสร็จ ใครที่พอช่วยเราได้ก็ไปคุยกันต่อนอกรอบ
***ถ้าพูดครบแล้วเสร็จก่อนเวลาก็โอเคนะ ขึ้นกับจำนวนคนในทีมด้วย ที่เคยเจอ เฉลี่ยจะพูดคนละ 1-2 นาที
9. มีการคุยกลุ่มย่อย เนื่องจากสมาชิกในทีมก็มีมาใหม่บ้าง หนูก็เลยอัธยาศัยดีหน่อย ชวนคนนั้นคนนี้คุยบ้าง
10. feedback ตรง คุยกันเลยอย่าอ้อม แต่ต้องใช้ศิลปะในการพูด ไม่งั้นอาจจะจำให้มีปัญหาในทีมได้
11. เริ่มทำงานไม่ตรงเวลา อันนี้เป็นปัญหาคือ เวลาเริ่มทำ Sprint เราตกลงกันว่า 9:30 แต่ทีมบางคนยังมาไม่ถึง ก็ทำให้เกิดความล่าช้า
12. คุยนาน นอกเรื่อง
13. ทีมที่เหลือยืนเฉยตอน SoS เวลาที่เราส่งตัวแทนออกไปทำ Scrum of Scrum ทีมทุกคนควรจะหางานทำ อย่างเช่น ตรวจสอบว่าเครื่องพร้อมทำงานหรือไม่ หาความรู้เพิ่มเติม หรือเทรนให้กับคนที่เข้ามาใหม่ เวลาที่ว่างๆก็ตอน ยืนรอ SoS 10 นาที และรอ Esstimate 10 นาที
14. คน Lead วนอยู่ 2-3 คน พี่เค้าบอกว่าควรจะเปลี่ยนกัน หมุนเวียนกันออกไปทำกิจจกรรม เพราะถ้าออกไปทำคนเดียว คนเดิมๆ จะทำให้คนๆนั้นรู้สึกไปว่าตัวเองเป็นผู้นำ เป็นผู้ตัดสินใจ แล้วจะไม่ถามความเห็นของทีม
16. โดนหลอกกเรื่องคนเพิ่ม คนเพิ่มมาไม่ได้หมายถึงมีทรัพยากรที่เพิ่มขึ้น แต่หมายถึงการสื่อสารที่เพิ่มขึ้น
17. ขายไอเดียให้ PO (ทำอะไรได้ ไม่ทำเสียอะไร) คือตอนที่คุยกับ PO เราก็พยายามขอว่าทำได้แค่นี้ ต้องทำอันนี้ก่อน แต่เราอธิบายในมุมของ Dev เกินไปบางที PO อาจจะไม่เข้าใจว่าทำไมต้องทำ ทำไปแล้วเขามีส่วนได้ส่วนเสียยังไง อันนี้เป็นหน้าที่ของ Dev แล้วว่า เขียนโปรแกรมเก่งไม่ได้อย่างเดียว ต้องขายของเป็น
18. ความรู้สึกมีส่วนร่วม
19. ความเชื่อใจของ PO เป็นผลเนื่องจาก ถ้าเราเคยรับปากจะทำ แล้วทำไม่ได้ไม่ตรงตามเป้า เป็นสักสองสามครั้ง PO ก็จะเริ่มลดความเชื่อใจในทีมลงไป เพราะฉะนั้นเราต้องประเมิณให้ดี ใกล้เคียงกับความสามารถมากที่สุด
Test Search By Cucumber (Automate Test)
วันนี้ได้ลองนั่งเล่นระบบค้นหาสินค้า เราค้นหาคำว่า "สีขาว"เพราะอยากลองซื้อสินค้าที่เป็นสีขาว ปรากฎว่ามันไม่เจอ แต่ในฐานข้อมูลมีสินค้าที่ประกอบด้วยคำว่า "สีขาว" อยู่มากมายเช่น กระดาษสีขาว ซองสีขาว
เราก็เลยไปเปิด facebook แล้วเจอพี่รูฟบอกให้ทำ Automate Test จากนั้นก็เลยเอามาปรึกษากับพี่ซุป (Supervisor) ว่ากรณีข้างต้นเนี่ย เหมาะกับ Automate Test หรือเปล่า ทำดีมั้ย ช่วยอะไรพี่ๆได้บ้าง หลังจากนั้นก็มัดมือชก บอกพี่เค้าว่า หนูจะทำ พี่เค้าก็ให้ไปเขียนว่าอยาก Test อะไร
กนกอร : พี่ๆ ปัญหาหนูคือ ไม่อยากมานั่งกรอกข้อมูลแล้วกดปุ่มค้นหา แล้วดูด้วยสายตาว่า list ที่ค้นหาออกมาเป็นร้อยๆตัวมีคำที่เราต้องการหรือไม่
วีรศักดิ์ : ทำได้ งั้นไปหาเครื่องมือก่อนจะใช้อะไรดี
พี่เค้าให้ลอง Geb เพราะมันน่าจะเข้าใจง่าย ลองอ่านดูแล้ว ก็พอเข้าใจ ตกลงเรียบร้อย ว่าเอาตัวนี้ แต่พอมาลงมัน Error ไม่รู้เพราะอะไร
สุดท้ายเลยเปลี่ยนไปใช้ Cucumber
สิ่งที่ต้องเตรียม และวขั้นตอนการทำ
1. ลง ruby ก่อน
2. ลง bundle ผ่าน gem ด้วยคำสั่ง gem install bundle
3. สร้างโครงสร้างสำหรับ Gem floder สามารถ Download โครงสร้างไฟล์ได้ ที่นี่
***ในภาพนี้ได้สร้างไฟล์ Test_Search_Paperplus.feature ไว้ในโฟลเดอร์ชื่อ "features" เพื่อใช้ในการเขียน Feature ที่เราต้องการ
4. แก้ไข Feature ที่เราต้องการ
ในภาพนี้ เราจะใช้พิมพ์ในลักษณะที่เป็นคำพูด ประโยคบอกเล่าสิ่งที่เราต้องการอยากจะได้ แปลได้ประมาณว่า ในการทดสอบการค้นหาสินค้า ให้เข้าสู่เว็บไซต์ 5555paperplus แลล้วเมื่อค้นหาด้วยคีย์เวิร์ด... หลังจากนั้นจะได้ผลลัพธ์ที่มี Title ตามคีย์เวิร์ดที่ค้นหา
ปกติถ้าต้องการ Test Case เดียวไม่ต้องใส่คำว่า Outline เพราะการใส่คำนี้ไป มันจะสามารถเพิ่ม Attribute "Examples" ให้สามารถทำ Test ได้หลายๆตัว
แปลแล้วงง อ่านในภาพดีกว่า อิอิ
6. ใช้คำสั่ง cucumber ใน Terminal ระบบมันจะจัดการสร้างไฟล์ให้เราเองอัตโนมัติในโฟลเดอร์ "step_definitions" ชื่อว่า "(ชื่อไฟล์ Feature).step.rb"
ตัวสีเหลืองๆคือคำที่มัน Ganerate ให้ ถ้าเรากลับไปดูที่โฟลเดอร์ เราต้องแค่ แก้ไขที่เราต้องการ และกด save
7. แก้ไขเพื่อให้มันทำ Automate Test โดยดูคำสั่งอ้างอิงจากเว็บนี้ก็ได้ https://gist.github.com/zhengjia/428105
จะเห็นว่าในโค้ดมันจะมีคำว่า pending ประมาณว่า ยังไม่สนใจ เราจะแก้ไขโค้ดที่เราต้องการใส่ไปตรงนี้
อย่างเช่นในภาพ
visit คือการไปเยี่ยมเว็บไซต์ ชื่อ www2.555paperplus.com
fill_in ไปทำการเติมคำลงไปใน input ด้วยคำที่เรากำหนด Spec ไว้ผ่านตัวแปร mykeyword
click_link สั่งให้คลิ๊ก link ที่มีคำว่า ค้นหาสินค้า
page.should have_css ระบบจะไปหาในหน้านั้นว่า
<li class="title">arg1</li> มี text ที่เรากำหนด Spec ไว้ผ่านตัวแปร arg1 หรือเปล่า
8. หลังจากเขียนเรียบร้อบแล้ว ก็พิมพ์คำสั่ง cucumber ใน Terminal และรอดูผลลัพธ์
เราสั่งให้มันเข้าเว็บไซต์ พิมพ์เองอัตโนมัติ และพอจบเราก็มาดูผลลัพธ์ที่ Terminal ว่า Success หรือ Fail ที่ไหน อย่างเช่นในภาพ สามารถค้นหาคำว่า "กล่อง" แล้วเจอผลลัพธ์ที่มีคำว่า "กล่อง" ประกอบ (ผ่านจะเป็นสีเขียว) แต่ค้นหาคำว่า "สีขาว" แล้วไม่เจอผลลัพธ์ที่มีคำว่า "สีขาว" ประกอบอยู่ด้วย
สรุป
- การให้ระบบทำ Automate Test เราจะไม่ต้องมานั่งพิมพ์มือ แล้วใช้สายตามองหาสิ่งที่ผิด ระบบมันทำให้อัตโนมัติเลย
- เขียน Spec เข้าใจง่ายๆเป็นประโยคอ่านเข้าใจ ไม่ใช้โค้ดในการอธิบาย