T-Bone in TK Park

วันนี้พาคุณลูกไปเที่ยว TK park
บังเอิญโชคดีว่า TK park เชิญ T-Bone มาแสดงพอดี
เลยมีบุญได้ฟังการแสดงสดอย่างไกล้ชิด
โดยไม่ต้องไปเสียสุขภาพ อดหลับอดนอนไปรอฟังที่ Saxophone
เนื่องจากสถานที่ไม่ใหญ่โต คนก็ไม่เยอะ
เลยได้นั่งฟังอย่างไกล้ชิด

ผมไม่ได้ฟังการแสดงสดมานานมากแล้ว
เลยรู้สึกดีเป็นพิเศษ
ส่วนคุณลูกด้วยความที่เล่นมาทั้งวัน
พอฟังได้เพลงครึ่งก็ซบพ่อหลับไป
(beat ขนาดนั้น, เสียงก็ดัง, มันยังหลับได้อีก)

ระหว่างเล่น ก็มีเสริมความรู้ให้ด้วยนะ
เช่น อธิบายว่า สกากับเร็คเก้ ต่างกันอย่างไร
มีความเป็นมาอย่างไร
เสร็จแล้วก็เล่นเพลงเดียวกันเปรียบเทียบให้ดู
เริ่มจากสไตล์ jazz ก่อน
จากนั้นก็ลองเล่นเป็น ska
สุดท้ายก็เล่นเป็นเร็คเก้

ช่วงกลางๆมีเล่นเพลง เธอเห็นท้องฟัานั่นไหม
ได้ยินแล้วรู้สึกตัวเองแก่ทันที
ในหัวมันมีประโยคหนึ่งผุดขึ้นมา
"กาลครั้งหนึ่ง นานมาแล้ว..."

Spring return LinkList

อาจารย์มะนาว พึ่งเขียน ชื่นชอบสุดๆ
ในนั้นมี link เรื่อง The departure of the hyper-enthusiasts
ที่วิจารณ์พวก ruby + rails ที่กำลังสนุกกันมากไปหน่อย

เรื่องศาสนา กับความชอบ ผมไม่สนใจเท่าไร
ที่สนใจก็คือใน post มี quote ที่พูดถึง container
ว่าทำไม interface ใน List ของ java ไม่มี getLast() แบบที่ ruby มีใน Array

วันนี้อ่าน Sanjiv Jivan 's Blog
เจอ post know how to iterate พูดถึง spingดframework jdbc helper
มัน return List ที่เป็น linkList ออกมา
ถ้าคนไม่รู้ ดันไปใช้คำสั่งพวก

for (int i = 0; i< list.size; i++) {
  X x = (X) list.get(i)
}

ถ้า data เยอะมากๆ , แตะหลักแสนเมื่อไร รับรองว่าเจอฝันร้ายด้าน performance แน่นอน

ใน post ได้อ้างถึง benchmark
ลองดูเวลาระหว่าง ArrayList กับ LinkedList

--------------------- ArrayList ---------------------
 size     add     get     set iteradd  insert  remove
   10     121     139     191     435    3952     446
  100      72     141     191     247    3934     296
 1000      98     141     194     839    2202     923
10000     122     144     190    6880   14042    7333
--------------------- LinkedList ---------------------
 size     add     get     set iteradd  insert  remove
   10     182     164     198     658     366     262
  100     106     202     230     457     108     201
 1000     133    1289    1353     430     136     239
10000     172   13648   13187     435     255     23

ส่วนวิธีที่ถูกต้องในการ access LinkList คือใช้ iterator

ProjectEuler

พักนี้ใน mailing list ของ Haskell
มี newbie ถามประเด็นคำถาม เกี่ยว program
ที่เกี่ยวข้องกับโจทย์ทางคณิตศาสตร์ ถี่ขึ้น (ถี่ในที่นี้ หมายถึงประมาณ 1-3 ฉบับต่อเดือน)
เมื่ออ่านรายละเอียดก็พบว่า โจทย์นั้นมีที่มาจาก ProjectEuler
ซึ่งเป็น site ที่มีการตั้งโจทย์ทางคณิตศาสตร์ แล้วให้เขียนโปรแกรม solve หาคำตอบ

หลังจากตาม mailing list ไปที่ site นี้เป็นครั้งที่ 3
ผมก็เลยตัดสินใจลองเล่นดูบ้าง
เพื่อจะได้ฝึก programing ด้วย haskell และ ฝึกใช้สมองที่มีจุดอ่อนในส่วนคณิตศาสตร์

หลังจาก register และ login แล้ว
จึงรู้ว่ามันมีหน้าสถิติให้ดูด้วย
ซึ่งสถิติที่ผมสนใจคือตัวนี้



จากจำนวน active user 2242 คน
มีคนระบุสัญชาติ 1555 คน
เป็นอเมริกันเสีย 338 คน -> 20 %
รองลงไปคือ สวีเดน 146 คน

ลองไล่ดูกลุ่มรองลงไปบ้าง

อังกฤษ 82
เยอรมัน 84
อินเดีย 85
แคนาดา 74

กลุ่มรองลงไปอีก

โปรตุเกส 52
ออสเตรเลีย 48
รัสเซีย 44
เนเธอร์แลนด์ 39

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

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

จำนวนคนที่มาจากเวียดนาม คงบ่งบอก อนาคต บางอย่างให้เห็นได้เลาๆ

Version Control

เห็นข้อมูลหนังสือ Ship It เขาอ้างว่า
ที่อเมริกา ยังมี project ที่ไม่ได้ใช้พวก SCM อยู่ประมาณ 40 %
อืมม์อยากรู้จังว่าบ้านเรา มีกี่เปอร์เซนต์
คงจะมากกว่า 40 อย่างแน่นอน

ในส่วนตัวผมในแง่งานที่บริษัทฯ, ใช้ SCM มาได้หลายปีอยู่
โดยเริ่มจาก CVS แล้วก็เปลี่ยนมาเป็น SVN
สถานะปัจจุบัน "ชีวิตนี้ขาด SCM ไม่ได้แล้ว"
(prototype บางอัน ทำแค่คนเดียว ยังอุตส่าห์ใส่ SCM ด้วย)

แน่นอนว่าหลังจากเปลี่ยนมาใช้ SCM แล้ว
คุณภาพชีวิตย่อมดีขึ้นแน่นอน
แต่ก็ยังมีประเด็นเล็กๆน้อยที่ยังต้องตามแก้ไขต่อ เช่น

• การใช้อะไรที่มากกว่า trunk
  ข้อนี้พบว่า developer ที่บริษัทผม ใช้ SCM ในการ develop main trunk เพียงอย่างเดียว
  ไม่มีใครเคยใช้ branches แม้ว่าสภาพงานบางงานเอื้อให้เกิด branch เสียเหลือเกิน
  (โปรเจคที่บริษัทฯ ส่วนใหญ่ไม่มี release
  เพราะเป็นโปรเจคแบบลูกค้าคนเดียว
  แถมยัง evolve ไปเรื่อยๆด้วย)
  
• นิสัยในการแก้ไข code
  มี developer หลายๆคนที่ยังติดความเคยชินเก่าๆ ในการแก้ไข source code อยู่ เช่น
  สมมติ เรามี
  

  x = 1.2 * y

  
  ถ้ามีการแก้ไขขึ้นมา เช่นเปลี่ยน constant ที่ใช้คูณ
  แทนที่จะแก้ตรงๆ ก็ดันไปทำแบบนี้แทน
  

  // x = 1.2 * y
  x = 1.3 * y

  
  คือยังทำเหมือนกับไม่ได้ใช้ SCM
  ส่งผลให้ทั้ง source code และผลลัพท์ที่เกิดจากการ diff version, ดูรกหูรกตา
  
• วิธีการ commit
  บางคนยังชอบไล่ commit ที่ละ file
  แทนที่จะทำ commit เป็น set ของการเปลี่ยนแปลง
  (ซึ่งจะทำให้การไล่อ่าน history หรือ ตรวจติดตาม change มันง่ายกว่า)
  
• การใส่คำอธิบาย ในส่วนของการ commit
  อันนี้ก็คงประเด็นต่อเนื่องมาจาก comment
  ก็คือ ในเมื่อ comment ใน code ยังใส่น้อยอยู่เลย
  นับประสาอะไรกับ comment ใน changeset
  

กรรม เป็นผลจากการกระทำ

ยิ่งเขียนโปรแกรม ผมก็ยิ่งซึ้งกับเรื่อง "กรรม"
ยิ่ง maintain โปรแกรมเก่าเรามากเท่าไร ก็ยิ่งซึ้งมากขึ้นเท่านั้น
quick fix นี่ตัวดีเลย,

ยกตัวอย่าง quick fix หนึ่งของผม
สมัยเมื่อนานมาแล้ว
มีโปรเจคอยู่โปรเจคหนึ่งซึ่งเป็นโปรเจค ลูกเมียน้อย
(หมายความว่า ไม่ได้ถูกให้ความสำคัญทั้งจากคนจ้างและคนรับจ้าง)
ซึ่งผมต้องทำ prototype ไปให้ user ใช้
มีอยู่หน้าจอหนึ่ง มันขาด field ไป field หนึ่ง
เผอิญใน table มันมี field หนึ่งที่พึ่งถูกตัดทิ้งไป
ก็เลยหยิบเอามาใช้ก่อนเลย ทั้งที่ naming,datatype มันคนละเรื่องคนละราวเลย

เผลอแป๊บเดียว โปรเจคลูกเมียน้อย
เกิดกลายเป็นทายาทมรดกร้อยล้านขึั้นมา
data วิ่งเข้าไปเป็นหลาย ล้าน record แล้ว
โปรแกรมก็มีหน้าจอเกินหลักร้อยไปเยอะแล้ว
การ refactor เปลี่ยนชื่อ column ใน table กลายเป็นเรื่องใหญ่

ช่วงนี้มีการ upgrade ตัวโปรแกรม
จากหน้าจอ terminal ขึ้นมาเป็น web application
ชื่อ column ที่ quick fix ไว้ก็เลยโผล่ขึ้นมาหลอกหลอน

จริงๆกรรมนี้ถือเป็นกรรมเล็กๆน้อยๆ
กรรมใหญ่กว่านั้นนี่ยังมีอีกหลายนัก

Note: เรื่อง กรรม นี้ คงใช้ได้กับบุคคลที่ไม่ได้เปลี่ยนงานบ่อย
ส่วนพวกเปลี่ยนงานหลังโปรเจคจบ ก็สบายตัวไป
(ไปได้กรรมอีกประเภทคือ ไม่เคยได้อยู่ดู feedback
ซึ่งถือว่าเป็นประสบการณ์ที่ช่วยพัฒนาตัวเองดีนักแล)