Monthly Archives: May 2012

RedDotRubyConf 2012 วันที่ 2

ต่อจากเมื่อวันก่อนนะครับ RedDotRubyConf 2012 วันที่ 1

วันนี้ในช่วงเช้าเหมือนคนจะมาน้อย แต่พองานเริ่มไปซักหน่อยก็มากันถึง 80% – 90% เหมือนกัน หัวข้อที่พูดในวันนี้ก็มีดังนี้

  • Redis on Ruby โดย OBIE FERNANDEZ จาก DUE PROPS / HASHROCKET คนนี้เป็นคนเขียน The Rails 3 Way ครับ เค้าบอกว่าเค้าเริ่มใช้ Redis เป็นส่วนเสริม relational database แต่ก็มีแนวโน้มจะใช้มากขึ้นเรื่อยๆ เพราะเค้ารู้สึกว่ามันสะดวกกว่าที่เค้าต้องไปทำ migration กับ relational database อยากได้ data อะไรก็ทำได้รวดเร็ว เค้าใช้ไลบราลีช่วยในการ map ระหว่าง Redis key กับ object data ช่วยแก้ปัญหาการจัดการ namespace ของ key จำนวนมหาศาลได้เป็นอย่างดี
Imag0477
Imag0480
  • Git Secrets โดย ZACH HOLMAN จาก GITHUB คนนี้เป็นตัวแทนของ Github ไปพูดตามงานต่างๆ บ่อยมากทีเดียว เค้ามาแนะนำฟีเจอร์ต่างๆ ใน Github ที่ไม่ได้โปรโมท หรือคนไม่รู้จักเท่าไหร่ (ใครรู้บ้างว่าใช้ svn checkout ออกจาก github ได้) เค้าบอกว่ามีคนชอบมาถามว่าทำไมไม่มีปุ่มของฟีเจอร์โน้นนี้ เค้าเลยตอบว่าถ้า github มีปุ่มของทุกฟีเจอร์จะกลายเป็นเหมือนรูปในสไลด์ข้างล่างนี้ครับ  และก็พูดถึงฟีเจอร์ของ git ด้วย ชอบสไตล์การพูดของคนนี้ที่สุดเลยในงานนี้ หลังจากนั้นก็ไปขอสติกเกอร์เค้ามาประดับโน้ตบุ๊คหน่อย
Imag0526
Imag0491
  • `bundle install`: Y U SO SLOW โดย TERENCE LEE จาก HEROKU คนนี้เค้าเป็น contributor ของ bundler มาพูดถึงความเปลี่ยนแปลงของ bundler จนถึงเวอร์ชั่น 1.2 ที่กำลังจะออกมา เค้าบอกด้วยว่ามีความพยายามจะตัด bundle exec ออกอยู่(เย่) คอยติดตามได้ใน 1.3
Imag0520
  • Computer Scientist, Developer, or Engineer? โดย CARL CORYELL-MARTIN จาก {NEW CONTEXT} หัวหน้าใหญ่จาก {new context} มาพูดแสดงแนวคิดว่า การใช้ชีวิตให้คุ้มค่าในฐานะนักพัฒนา คือ การสร้างซอฟแวร์ที่สร้างคุณค่าให้แก่โลกใบนี้
  • Run Ruby Run โดย SEBASTIAN BURKHARD จาก FUNDEXPLORER มาแนะนำเทคนิดการเขียนโค้ดให้ทำงานเร็วขึ้น เช่น การใช้แคช
  • Level Up and switch from JS to CoffeeScript โดย GABE HOLLOMBE จาก TUTORING AUSTRALASIA มาเผยแพร่ศาสนา CoffeeScript ครับ
Imag0509
  • API-Driven Development โดย DARCY LAYCOCK จาก FILTER SQUAD คนนี้มาแนะนำข้อควรระลึกเบื้องต้นเกี่ยวกับการทำ Web API และแนะนำไลบราลีต่างๆ ที่ช่วยในการทำ สไลด์ของเค้าอยู่ที่นี่ครับ
  • Lessons From the Other Side: Effectively Contributing to Open Source โดย MICHAEL “KOZ” KOZIARSKI จาก SOUTHGATE LABS คนนี้เป็น core contributor ของ Rails มานานมาก มาเล่าถึงสิ่งที่ควรทำ และไม่ควรทำในการ contribute
    • คน contribute เยอะกว่า issue มากๆ ในสไลด์มีรูป github notification ของเค้าแสดงเป็นอินฟินิตี้
    • เค้าทำผิดพลาดปิด issue ของคนอื่นที่มีประโยชน์ก็หลายครั้ง เค้าบอกว่าถ้าโดนปิดก็ให้ท้วงมา ถ้าเค้าไม่สนใจก็ให้พยายามท้วงผ่านคนอื่นที่เคย contribute มาก่อน เค้าจะค่อนข้างฟังคนพวกนั้นมากกว่า
    • ถ้าใครมาบ่นเรื่องฟีเจอร์ แล้วมีคำว่า “ผมไม่ใช้ Rails เพราะ ….” เค้าจะไม่สนใจเลย เค้าทำให้เฉพาะคนที่อยากจะใช้ครับ
    • ควรส่ง pull request ทีละเล็กๆ ง่ายๆ พร้อมคำอธิบาย จะมีโอกาสได้ merge สูงกว่ามาก
    • ให้เริ่ม contribute สิ่งที่มีประโยชน์ต่อตัวเอง อย่าไปควานหา issue เพื่อจะ contribute
  • Andy Croll คนจัดมาพูดปิดงาน เค้าเปิดสไลด์ที่มีรูปใบหน้าของ speaker ทุกคน ไฮไลต์ทีละคนและพูดสรุปหนึ่งประโยคถึงสิ่งที่คนนั้นพูดในงาน ได้อย่างเท่มากๆ

หลังจากจบงานก็แยกย้ายเดินทางไปร้าน NABINS กัน ปิดชั้น 2 ของร้าน ใช้โทเคนที่ได้รับแจกเมื่อวานนี้หนึ่งใบ แลกเบียร์ขวดเล็กได้หนึ่งขวด ส่วนมากก็คุยอยู่กับกลุ่มที่มาจากไทย คุยภาษาอังกฤษบ้าง ไทยบ้างขำดี ได้รับรู้ถึงพลังของพี่ tanin ผมเชื่อว่าเค้าต้องประสบความสำเร็จแน่ๆ เลย

ปีหน้าพยายามจะไม่พลาดครับ

Advertisements

ที่มาของหัวเกรียน

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

ความเกรียนครั้งนี้ไม่เกี่ยวอะไรกับสิ่งต่อไปนี้ทั้งนั้น

  • อกหัก
  • เชลซีได้แชมป์ UCL
  • ทำคีโม
  • เป็นเหา
  • เขียนโปรแกรมจนตบะแตก
จริงๆ แล้วคือผมตัดตามเต้ยครับ (ไม่ใช่ละ)

เรื่องมันมีดังนี้

ผมไปตัดผมที่ร้านราคา 8 SGD ซึ่งถูกที่สุดที่เท่าที่เคยเห็นมาแถวนี้ ซึ่งครั้งนี้เป็นครั้งที่ 3 แล้วที่ไปตัด ครั้งแรกตัดไม่ค่อยถูกใจเท่าไหร่ ครั้งที่สองเลยเตรียมรูปไป ตัดได้ถูกใจมาก ครั้งที่สามนี้จึงก็เตรียมรูปไปเช่นเดิม แต่แล้ว…

สภาพร้านเป็นห้องเล็กๆ หนึ่งห้อง มีโต๊ะตัด 3 โต๊ะมีช่างประจำโต๊ะ ไปแต่ละครั้งช่างไม่เคยซ้ำคนเลย ต้องทำการซื้อบัตรด้วยตู้อัตโนมัติ เสียบแบงค์ 10 SGD เข้าไปจะได้การ์ดมา แล้วก็ยืนรอคิว เมื่อช่างว่างก็เดินเข้าไป ช่างก็จะคืนเงินมาให้ 2 SGD

เมื่อเข้าไปนั่ง ผมก็ทำการควักรูปมาให้ดูบอกว่าเอาแบบนี้ มันก็อืมๆ ก็คิดว่าโอเคละ

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

แต่หลังจากนั้น สิ่งที่ผมไม่คาดฝันก็เกิดขึ้น ช่างควักแบตตาเลี่ยนออกมาไถด้านข้าง เห้ยรูปที่ให้ดูนี่ด้านข้างเกรียนตรงไหน แล้วดูท่าแล้วจะได้ทรงผมแบบว่าด้านข้างเกรียนด้านบนยาวซึ่งไม่ชอบมากๆ ก็เลยบอกเค้าว่ามันสั้นเกินไปละ สกินเฮดเลยละกัน ปรากฎณ์ว่ามันฟังไม่รู้เรื่องครับ ต้องเรียกเพื่อนข้างๆ มาแปลให้ ถึงบางอ้อเลยทีเดียวว่าพูดภาษาอังกฤษไม่ได้

หลังจากนั้นเค้าก็ยังพยายามแต่งข้างบนอยู่ จนสุดท้ายก็ต้องว่า “Everything” ถึงจะรู้เรื่องและได้ทรงนี้มา สกินเฮดนี่ยังบอกยากขนาดนี้

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

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

RedDotRubyConf 2012 วันที่ 1

http://reddotrubyconf.com/

Imag0472

เป็นงานสัมมนาเสียเงินครั้งแรกในชีวิตของผม

งานนี้คนร่วมงานกว่า 200 คนได้ แต่ก็พบคนรู้จักคุ้นหน้าคุ้นตาเยอะอยู่เหมือนกัน บริษัทผมยกทีมเอ็นจิเนียร์ไปทั้งหมดบริษัท บริษัท {new context} ที่สนิทกันเป็นอย่างดีก็ยกไปทั้งบริษัท เพื่อนร่วมงานบริษัทเก่า และคนที่พบเจอตามงาน meetup ต่างๆ ก็มางานนี้กันเยอะทีเดียว แถมยังมีคนที่มาจากไทยทั้ง @tanin47, @shr@LukeInTH ด้วย

มาดูของแจกกันก่อน

ลงทะเบียนงานได้เสื้อยืดหนึ่งตัว พร้อมลูกบอลยางสีแดงหนึ่งอัน และโทเคนสำหรับแลกเครื่องดื่มในงานเลี้ยงเย็นวันที่ 2

ระหว่างงานได้โค้ดโหลด PeepCode ฟรี 1 ตอน และ Andy Croll คนจัดงานบอกว่ากำลังจะได้ AWS ฟรีแต่ติดปัญหาเทคนิคนิดหน่อย

ตอนเที่ยงได้เสื้อจาก {new context} หนึ่งตัว และบัตรฟรี SoftLayer instace ฟรี 1 เดือน

Imag0474

เนื้อหาในงานก็ไม่ออก Ruby จ๋าเท่าไหร่ แค่มี Ruby เป็นหลักเท่านั้นเอง session เช้ามีดังนี้

  • Building a faster web, at Google and beyond โดย ILYA GRIGORIK จาก​ Google พูดถึงเรื่องการวิเคราะห์และปรับแต่งความเร็วของเว็บโดยเน้นที่ front-end แนะนำอุปกรณ์ใน Chrome, ค่าเวลาการโหลดเพจในเว็บบราวเซอร์ที่เราเข้าถึงได้ตามาตรฐาน W3C และแนะนำการใช้ Google Analytics เก็บข้อมูลความเร็วของเว็บของเรา เดาว่าเนื้อหาน่าจะคล้ายกับที่เค้าไปพูดที่ RailsConf ที่ผ่านมาเลย
  • The 12 Factor App โดย RICHARD SCHNEEMAN จาก HEROKU มาพูดถึงสิ่งที่ควรคำนึงถึงในการทำเว็บ ตามเนื้อหาในเว็บไซด์นี้ http://www.12factor.net/ ก่อนเริ่มได้มีการถ่ายรูป Friday Free Hug กันด้วย (หาผมเจอหรือเปล่า)
  • Building Web Services with a PUBSUB infrastructure โดย THORBEN SCHRODER จาก ENGINE YARD พูดถึงประสบการณ์การลองทำ PubSub server ที่มีการทำการยืนยันตัวบุคคล ของเค้าด้วย REDIS และ Lua
  • Continuous Performance Testing โดย ANDRAS KRISTOF จาก VIKI มาพูดถึงการพยายามผนวกการทดสอบ performance เข้าใน CI server โดยใช้แนวคิดที่ว่าพยายามทำให้ได้เร็ว ต่อเนื่องและประหยัดทรัพยากร โดยเน้นวัดแค่ประสิทธิภาพสัมพันธ์เท่านั้น ไม่ได้วัดประสิทธิภาพสัมบูรณ์

จากนั้นก็พักกินข้าวเที่ยงกัน อาหารเหมือนกับงาน CITCON เป๊ะ เพราะคนเตรียมอาหารที่ CITCON เล่าให้ฟังว่าเค้าถาม Andy Croll ว่าจ้างร้านไหน

Imag0462

จากนั้นก็เป็น session บ่ายครับ

  • The Γυβψ Community โดย DANISH KHAN จาก GITHUB มาพูดถึงสิ่งที่เค้าเห็นว่าเกิดขึ้นใน community แล้วไม่ควรทำ เช่น คนที่ทำ open source โปรเจ็คซึ่งมีคนใช้เยอะแล้วก็ทิ้งไปเลยโดยไม่บอกกล่าวใคร
  • Ruby, Rock & Roll โดย SAU SHEONG CHANG จาก HP LABS มาโชว์ไลบราลีสำหรับจากไฟล์เพลงที่เค้าเขียนขึ้นที่มีชื่อว่า Muse เค้าอธิบายตั้งแต่สมการการสร้างคลื่นเสียง จนถึงการสร้าง DSL มาคลุมไลบราลีของเค้า และเค้ายังโชว์งานต่อเนื่องของเค้าที่พยายามจะแปลง คำ ไปเป็น เพลง ตามอารมณ์ของประโยคนั้นด้วย แต่ตอนนี้ยังไม่ถึงขั้นนั้น ยังได้แค่เปลี่ยนคำเป็นเพลงด้วยอัลกอริทึมธรรมดาอยู่
  • CSS Testing: Designs Can Be Tested Too โดย WINSTON TEO จาก {NEW CONTEXT} มาโชว์ไลบราลีสำหรับทดสอบ CSS ของเค้าที่ชื่อว่า cactus ซึ่งเกิดจากแรงบันดาลใจที่ว่า CSS ในโปรเจ็คใหญ่ๆ มันเน่าเหลือเกินและไม่มีใครกล้าไปแตะต้องมันเพราะกลัวทำอะไรพังโดยไม่รู้ตัว สไลด์ของเค้าอัพแล้วที่นี่
  • Dive inside Ruby 1.9 โดย HEMANT KUMAR จาก CODEMANCERS มาพูดถึงสิ่งที่เปลี่ยนไปด้านล่างระหว่าง 1.8 กับ 1.9
  • Client-side Templating for Reactive UI โดย TIM OXLEY จาก UNIT IO เป็น โปรแกรมเมอร์ภาษา ๋avascript มาชวนคนจาก Ruby ไปเขียน Thick client
  • A Journey into Pair Programming โดย WEI LU จาก {NEW CONTEXT} เธอเพิ่งจบมาไม่นาน เลยมีโอกาสได้สังเกตประสบการณ์และความรู้สึกที่ได้รับจากการทำ pair programming กับคนที่มีความสามารถต่างๆ กัน มาเล่าให้ฟัง

ส่วนของพรุ่งนี้ จะตามมาครับ 🙂

Fundamental of successful software development?

ย้อนกลับไปไม่นาน ซัก 5 – 6 เดือนที่แล้ว เป็นช่วงที่ได้เริ่มทำงานโดยใช้ Agile จริงๆ เป็นครั้งแรก ตอนนั้นมีความคิดเต็มเปี่ยมว่าหน้าที่ของเราในฐานะ developer คือ การทำตามความต้องการของฝ่าย business(marketing, product, business development, …) เราต้องให้เกียรติเค้าในฐานะของคนที่น่าจะเข้าใจคนไม่ geek (ผู้ใช้งาน)มากกว่าเรา เราไม่ควรปฏิเสธไม่ทำตามความต้องการของเค้าด้วยเหตุผลทางการออกแบบของระบบ เราควรทำระบบของเราให้ยืดหยุ่นเพียงพอที่จะรองรับความต้องการที่เปลี่ยนแปลงไป

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

ในช่วงนั้นผมได้รู้จักแนวคิดหนึ่ง จากเพื่อนร่วมงาน และหนังสือเรื่อง Specification By Examples ว่า business มักไม่ได้บอกว่าเค้าต้องการอะไร เค้ามักจะบอกว่าเค้าจะให้เราทำอะไร ซึ่งหลายๆครั้งสิ่งที่เค้าบอกให้เราทำนั้น สุดท้ายแล้วเมื่อเราทำมันออกมา มันกลับไม่ได้เป็นสิ่งที่ทำให้ตัวเค้าเองพึงพอใจเลย

แนวทางแนะนำเพื่อใช้ในการแก้สถานะการณ์นี้คือ หาให้ได้ว่าจริงๆ ความต้องการจริงๆ ของเค้าคืออะไร โดยหนังสือแนะนำให้ใช้วิธี 5 Why? คือ ถามว่า “ทำไมต้องทำ” ซ้อนในคำตอบของเค้าไปเรื่อยๆ ประมาณ 5 ครั้งจะไปถึงต้นตอของความต้องการจริงๆ

เรื่องการค้นหาต้นตอของความต้องการนี้ ถ้ามองให้ลึกเข้าไปอีกมันคือ การค้นหาปัญหา ค้นหาว่าผู้ใช้งานมีปัญหาอะไร และจากนั้นก็หาวิธีแก้มัน

ผมได้ยินแนวคิดนี้บ่อยๆ ช่วงหลังมานี้ในวงการ startup ตัวอย่างเช่น Instagram ที่เค้าแก้ปัญหาการถ่ายและแชร์รูป* หรืออย่างบทความเรื่อง วิธีการเริ่มต้นเปิดบริษัทของตัวเองของ Paul Graham ก็มีการพูดถึงเรื่องนี้

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

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

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

*จำไม่ได้ว่าอ่านมาจากไหน