Monthly Archives: February 2013

เล่าถึง presentation Optimizing for Happiness by Github founder

แอบตกยุคนิดหน่อย เพิ่งจะมีโอกาสนั่งดู presentation เก่าพอสมควรซัก ปีกว่าๆ 2 ปีได้ ที่ชื่อว่า Optimizing for Happiness โดย Tom Preston-Werner  หนึ่งในผู้ก่อนตั้ง Github ซึ่งเค้ามาพูดถึงการบริหารงานบริษัทที่เค้ายึดหลักความสุขเป็นสำคัญ

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

ในด้านธุรกิจมีความน่าสนใจอยู่ตรงที่ว่าเป็นบริษัทที่ไม่ได้รับเงินทุนภายนอกช่วยเหลือในการตั้งบริษัทเลย มีกำไรตั้งแต่ 6 เดือนแรกและมีกำไรมาตลอด ปัจจุบันรับเงินลงทุนไปรอบนึง ประมาณ 100 ล้านเหรียญ ซึ่งถือว่าสูงมากสำหรับการรับเงินลงทุนรอบแรก และตลอดการดำเนินงานที่ผ่านมายังไม่มีพนักงานลาออกเลย (จากล่าสุดที่ได้ยินมามีเกือบ 200 คน)

ถ้า search หาหัวข้อการพูดนี้ จะพบว่ามี 2 เวอร์ชั่น อันนึงพูดที่ Startup School จัดโดย YC อีกอันพูดที่คอนเฟอเรนซ์ Ruby ที่อาเจนตินา สไลด์ของอาเจนตินาอยู่ที่นี่ครับ

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

ขอยกช็อตหล่อๆ ช่วงท้ายเวอร์ชันอาเจนตินามาให้อ่านกันนะครับ

เค้าจะพิสูจน์ว่าบริษัทที่จะเจริญเติบโตไปได้อย่างดี ต้อง Optimizing for Happiness

OPTIMIZING FOR HAPPINESS = INVESTING IN HUMANS

INVESTING IN HUMANS = A HAPPY TEAM

A HAPPY TEAM = A GREAT PRODUCT

A GREAT PRODUCT = HAPPY UESRS

HAPPY UESRS = PAYING CUSTOMERS

PAYING CUSTOMERS = MORE MONEY

MORE MONEY = A BETTER ABILITY TO OPTIMIZE FOR HAPPINESS

ใครสนใจเนื้อหาเต็มๆ ก็ลองไปดูไปฟังกันนะครับ

บริษัทไหนทำได้แบบนี้ แล้วหาคนทำงานไม่ได้ เอาผมไปทำงานด้วยเลยเอ้า!

Advertisements

โฆษณางาน RedDotRubyConf 2013

เนื่องด้วยรู้จักกับ Winston คนจัดงานเป็นการส่วนตัว และความอยากให้มีงานนี้ต่อๆ ไปเรื่อยๆ ขอเขียน blog ช่วยประชาสัมพันธ์หน่อยละกัน

อันนี้เป็นเว็บไซต์ของงานครับ RedDotRubyConf 2013

จริงๆ แล้วตัวงานก็มีความน่าสนใจในตัวมันเองอยู่ เนื่องด้วยมันเป็นงาน Ruby conference ที่ใกล้ไทยที่สุด รวมค่าตั๋วเครื่องบิน ที่พัก อาหาร การเดินทาง และตั๋วเข้างาน สามารถอยู่ได้ในงบ 15,000 บาท ส่วนใครจะถือโอกาสมาเที่ยวสิงคโปร์ด้วยก็ไม่ว่ากัน

งบระดับนี้หลายๆ คนอาจจะมองว่าค่อนข้างแพง สำหรับงาน 2 วัน แต่ช้าก่อนลองมาดูรายชื่อคนพูดกันครับ

Speaker ของงานปีนี้ผมถือว่าโหดมากๆ ครับ ลองมาไล่ดูรายคน

– Jim Weirich คนสร้าง rake ซึ่งเป็น build tool ที่เป็นมาตรฐานของ Ruby อยู่ในปัจจุบัน
– Josè Valim อยู่ใน top 5 ของ all-time contribution ของ Rails เป็นคนเขียน Devise gem สำหรับช่วงเรื่องการ authentication บน web ที่สะดวกมาก และเป็นคนเขียนหนังสือ Crafting Rails Applications
– Aaron Patterson นี่ก็ top 5 ของ all-time contribution อีกคน และเป็นคนเดียวในโลกที่เป็นทั้ง Rails core และ Ruby core ส่วนตัวผมชอบคนนี้เป็นพิเศษ ตามดูเค้าพูดอยู่ตลอดตามงานต่างๆ และชอบวิดีโอที่ Peepcode ไปจับเค้ามาน่ังเขียนโปรแกรมให้ดู เป็นคนที่มีอารมณ์ขันดีมาก
– Steve Klabnik 2011 Ruby Hero Award และคนเขียน drapper
– Akira Matsuda Ruby core และคนพูดเรื่อง Ruby 2.0 ที่งาน RubyConf 2012
– และ Prem Sichanugrist ความภาคภูมิใจของคนไทยเป็น Rails’s committer ทำงานอยู่ thoughbot ที่เป็นบริษัทที่เขียน gem ที่คน community Ruby ใช้กันอยู่มากมาย

จะเห็นได้ว่าได้คนเก่งๆ ใน Ruby community มาเยอะจริงๆ

อีกประเด็นนึงที่สำคัญสำหรับงานนี้ คือ เป็นโอกาสอันดีมากๆ สำหรับใครที่สนใจหางานทำที่สิงคโปร์ ผมเชื่อว่าจะต้องมีตัวแทนจากหลายๆบริษัทในสิงคโปร์และประเทศใกล้เคียง มาร่วมงานกันเป็นจำนวนมากแน่นอน และบริษัทเหล่านี้ส่วนใหญ่หาคนอยู่ครับ

ผมเคยเขียน blog ถึงงานเมื่อปีที่แล้วไว้ ใครสงสัยว่าบรรยากาศเป็นอย่างไร ลองไปอ่านกันดูได้ครับ

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

และใครจะมาบอกด้วยครับ เดี๋ยวนัดเจอกันๆ 🙂

มืออาชีพ 2

มืออาชีพ ต้องไม่ปล่อยให้ความกลัว ทำให้เสียระเบียบวินัย

เป็นประโยคที่ฟังแล้วชอบมาก จากตอนท้ายของ presentation เรื่อง What Killed Smalltalk Could Kill Ruby, Too ของ Robert Martin ในงาน RailsConf 09

ปล. 1 ที่ “2” เพราะว่าเคย เขียน ถึงมืออาชีพไปแล้วรอบนึง
ปล. 2 ขอบคุณพี่รูฟที่แชร์ link มาครับ

Test อะไรบ้าง?

มาเปลี่ยนเรื่องคุยกันหน่อยหลังจากไปอยู่ทาง Functional programming 2 บล๊อกติดๆ คราวนี้จะมาพูดกันถึงเรื่องที่ผมรู้สึกว่าบางทีผมก็รู้ บางทีผมก็รู้สึกว่าไม่รู้ แปลกๆยังไงชอบกลกันบ้าง เรื่องนี้คือ testing ครับ

testing ที่จะมาพูดในวันนี้ ผมได้ปัญหามาจากบทสุดท้ายในหนังสือ Practical Object-Oriented Design in Ruby ครับ มีประโยคนึงที่ผมทำ highlight ไว้เพราะคิดว่ามันน่าสนใจ สามารถนำไปเป็น guideline ในการเขียน test ได้อย่างดี แต่ก็ยังไม่ค่อยเข้าใจเท่าไหร่ ขอคัดมาบางส่วนตามนี้ครับ

Guidelines for what to test: Incoming messages should be tested for the state they return. Outgoing command messages should be tested to ensure they get sent. Outgoing query messages should not be tested.

(คนเขียนเค้าเป็น OO สาย smalltalk เค้ามอง method, function เป็น message ที่ส่งระหว่าง object ครับ  ซึ่งจากประโยคด้านบน message == method/fucntion)

ในหนังสือเล่มนี้เค้าพูดถึงแต่ unit และ isolation test ผมจึงตีความว่าประโยคข้างบนนี้พูดถึงแค่ unit และ isolation test เช่นกัน

เค้าบอกว่า ให้ test message ขาเข้า (incoming) ด้วยการตรวจผลลัพธ์ ส่วน message ขาออก(outgoing) ให้ทดสอบเฉพาะ message ที่เป็น command message คือ message ที่ไปสั่งให้ object อื่นทำงาน ไม่ได้ต้องการค่ากลับมา (หรือเรียกตามประสา functional ว่า side-effect นั่นเอง) ส่วน message ขาออกที่เป็น query message คือ message ที่ส่งไปเพื่อถามค่า คาดหวังค่ากลับมา ไม่ต้องทำการ test

ตัวอย่าง ข้างล่างนี้ calculate คือ incoming message, price_for คือ outgoing query message  และ decrease คือ outgoing command message

class Cashier
  def initialize(item_price, stock_control)
    @item_price = item_price
    @stock_control = stock_control
  end

  def calculate(items)
    prices = items.map { |id, amount| @item_price.price_for(id) * amount }
    items.each do |id, amount|
      @stock_control.decrease(id, amount)
    end
    prices.inject(0, :+)
  end
end

ผมสงสัยว่า ทำไมเค้าถึงบอกว่าอย่า test outgoing query message ในหนังสือก็ไม่ได้อธิบายอย่างชัดเจน ลอง search หาจากเน็ตก็หาไม่เจอ เลยกลับตัดสินใจกลับไปวนอ่านซ้ำอีกหลายรอบ จนในที่สุดก็นึกถึงคำอธิบายที่พอจะเข้าเค้าขึ้นมาได้

ผมเข้าใจว่าเราไม่ควรทดสอบ outgoing query message ในระดับ unit และ isolation แต่เราควรทดสอบมันในระดับที่สูงขึ้น เช่น integration, functional, acceptance, end-to-end เพราะว่าการทดสอบ outgoing query message ในระดับ unit และ isolation นั้น ทำให้เราผูกติดกับ dependency มากเกินไป เป็นการรู้มากเกินไปว่า dependency ของ class Cashier นั้นเป็นใคร มันไม่ใช่สิ่งที่ระดับ unit ควรจะรู้

การเขียน test นั้น  เปรียบเสมือนการจำลองตัวเองเป็นผู้เรียกใช้งาน ในฐานะผู้ใช้งานเราไม่ควรจะต้องรู้ว่า calculate มี dependency เป็นใคร เราควรรู้แค่ว่า calculate ทำอะไรให้กับระบบโดยรวมบ้าง ซึ่งถูกสะท้อนออกมาโดยการ test incoming message และ outgoing command message การที่รู้มากเกินไปในระดับ unit ทำให้เกิดปัญหาตามมา ทั้ง test พังง่าย แก้อะไรนิดหน่อยก็พัง และทำให้เรา reuse Cashier ได้ยากขึ้นด้วย เพราะความคิดจะติดอยู่กับว่า item_price จะต้องเป็น class ที่ return ค่านั้นค่านี้เสมอ แล้วเราจะเปลี่ยน implementation ของ item_price ได้อย่างไร

ในหนังสือผู้เขียนมีการเน้นย้ำบ่อยครั้งว่า เราควรเขียน code และ test ผูกกับสิ่งที่ไม่เปลี่ยนแปลง (interface) ในที่นี้คือ calculate และ decrease และปล่อยส่วนที่เหลือให้เป็นอิสระเปลี่ยนแปลงได้ จะทำให้ code เรา reuse ได้ง่ายขึ้น และเขียน test ได้ดีขึ้นด้วย

อย่างที่บอกไปว่าเราไม่ test ในระดับ unit แต่เราจะไป test ในระดับที่่สูงขึ้นแทน เพราะในระดับที่สูงขึ้นเรามีความรู้ในภาพรวมแล้วว่าระบบนี้ใช้ทำอะไร และต้องมี component อะไรเป็นส่วนประกอบบ้าง จะ test แค่การ integrate บางส่วน หรือจะทำ end-to-end ก็ตามความสะดวกและเหมาะสมเลยครับ

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