Saturday, September 09, 2006

กลุ่มคนที่สนใจ Erlang

ปกติในแวดวงของ erlang จะเงียบๆ ใครใช้ก็ใช้ไป
แต่หลังจากที่ Yariv Sadan เริ่มเขียน blog เกี่ยวกับ erlang
ก็ปรากฎว่ามีคนให้ความสนใจมากขึ้น

Yariv เขาเล่าว่า ก่อนเขียนเรื่อง erlang,
web เขามีคนมาเยี่ยมดูหลัก 10 คนต่อวัน
แต่พอหลังจากเขียนเรื่องนี้ จำนวนคนที่เข้ามาดูเพิ่มขึ้นเป็นหลักพัน

อันนี้้เป็นแผนที่ที่ได้จาก google analytic
แสดงว่า visitor มาจากที่ไหนบ้าง



ปล. ผมมั่นใจมากว่าจุดบน bangkok นี่ ของผมแน่นอน

Related link from Roti

Friday, September 08, 2006

Law of Demeter

ช่วงนี้หากินกับน้องๆในบริษัทดีกว่า
ลองดู statement ที่น้องใหม่เขียน
line = repOut.getPages().get(pageIndex-1).getLines().get(lineIndex-1);

วัตถุประสงค์ของบรรทัดข้างบน
ก็คือต้องการดึง current Line ขึ้นมา

ประเด็นก็คือ มัน(class ที่ implement method นี้)ล้วงลูกไปไกลเหลือเกิน
แถมยังรู้มากด้วย โดย method นี้รู้หมดว่า page เก็บอยู่ใน List Structure
ส่วน line ก็เก็บใน List เช่นเดียวกัน

ปัญหาของการล้วงลูก หรือรู้มาก ก็คือ
ในอนาคต ถ้ามีการปรับเปลี่ยน structure ของ page หรือ line เมื่อไร
จำนวน code ที่จะโดน effect ก็จะเยอะตามไปด้วย

ใน OO มันมีกฎอยู่ข้อหนึ่ง ก็คือ "Law of Demeter"
อธิบายสั้นๆว่า "Only talk to your friends"
ดังนั้นถ้าเขียนให้ถูกตามกฎของ Law of Demeter เราควรจะเขียนแค่นี้พอ
line = repOut.getCurrentLine()


Good fences make good neighbors.
Robert Frost, "Mending Wall"

** ประโยคเด็ดข้างบน ลอกจาก "The Pragmatic Programmer, from journeyman to master"
บทที่ว่าด้วยเรื่อง "Decoupling and the Law of Demeter"

Related link from Roti

Sun & JRuby

น่าสนใจมาก
Sun จ้างคนเขียน JRuby 2 คน เข้าทำงาน full time แล้ว
หน้าที่คือพัฒนา JRuby ให้แตะ 1.0 ให้ได้
และยังต้องคิดถึง developer tool ว่าควรจะเป็นอย่างไรด้วย

ส่วน licenses ของ JRuby ยังเป็น open source เหมือนเดิม

JRuby Steps Into the Sun
JRuby Shines in Sun
JRuby Guys

Related link from Roti

Thursday, September 07, 2006

ประตูสามบาน

เมื่อวันก่อนตอนประชุมกัน มีการหยิบยกโจทย์ประตูสามบานขึ้นมาคุยกัน
จำได้ว่าเคยอ่านเจอใน blog ของ ฮุ้ย ก็เลยไปค้นเจอหัวข้อ ปริศนาเกมส์โชว์
ในนั้นมีการอ้างถึงหนังสือ "Information Theory, Inference and Learning Algorithms"
ก็เลย download มาดูเฉลย

[กรุณาอ่านโจทย์ใน link ก่อน แล้วค่อยอ่านข้างล่างนี้]
ใน commonsense ของเรา เราก็ต้องบอกว่า chance ของการได้ทอง
มันเหลือ 50-50 แล้ว การเปลี่ยนหรือการไม่เปลี่ยน ควรจะมีความน่าจะเป็นเท่าๆกัน
แต่หลังจากอ่านเฉลย ทำให้เรารู้ว่ามันมี event หนึ่งที่เราลืมคิดไป
นั่นก็คือ event ของ พิธีกรเกมส์โชว์ ที่เลือกเปิดประตูเบอร์ 3
event นั้นมีการกระจายตัวที่ไม่เท่ากัน เช่น

สมมติว่าถ้าทองอยู่ที่ประตู 1, พิธีกร จะเลือกเปิดประตู 2 หรือ 3 ก็ได้
ดังนั้นโอกาสที่จะเปิดประตู 3 มีค่าเท่ากับ 50%
แต่ถ้าทองอยู่ที่ประตู 2 , พิธีกร มีทางเลือกแค่ทางเดียวในการเปิดประตู
ดังนั้นโอกาสที่จะเปิดประตู 3 มีค่าเป็น 100%

ในเฉลย เขาเอา Bayes' theorem เข้ามาคำนวณ
ซึ่งสำหรับคนที่ไม่คุ้นกับ language ทางคณิตศาสตร์ (เช่นผม)
ก็ต้องใช้เวลา absorb นานหน่อย

แต่สำหรับคนที่ขี้เกียจอ่าน math language
ก็มีเฉลยอีกแบบ ที่เขาเรียกว่า "more intuitive"
ก็คือให้ลองคิดโจทย์นี้ใหม่ โดยจับโจทย์มาขยาย scale
เปลี่ยนเป็นว่า มีประตูอยู่ 1,000,000 ประตู
เราเลือกประตูเบอร์ 1, พิธีกรเปิดประตู 999,998 ประตูที่เหลือ
เพื่อโชว์ว่าไม่มีทองในประตูเหล่านี้
ถามว่าเราจะยังเลือกประตูเบอร์ 1 อยู่หรือไม่ หรือจะเปลี่ยนไปเลือกอีกประตูหนึ่งดี

พอเปลี่ยน scale โจทย์มาแบบนี้ ก็เลย Bingo เลย
ถ้าเปลี่ยนประตู โอกาสชนะนี้เกือบ 100% เลย
เพราะในการเลือกครั้งแรก เรามี chance อยู่แค่ 1 ใน 1,000,000 เท่านั้นเอง

ps. ใน link ของฮุ้ยมีโปรแกรม simulation ที่ otto เขียนไว้
แต่เนื่องจากทืม mm.co.th กลับจากญี่ปุ่นกันหมดแล้ว
link ก็เลยหายไปด้วย
ผมเลยเขียนโปรแกรม simulate ใหม่ขึ้นมา
def rand_door
rand(3) + 1
end

def open_second_door(gold_door, first_guess)
doors = [1,2,3]
doors.delete(gold_door)
doors.delete(first_guess)
doors[rand(doors.size)]
end

def choose_left_door(first_guess, opened_door)
(1..3).each {|door|
return door if (door != first_guess && door != opened_door)
}
end

def play
gold_door = rand_door
first_guess = rand_door
opened_door = open_second_door(gold_door, first_guess)
left_door = choose_left_door(first_guess, opened_door)
result = gold_door == left_door ? "win" : "loss"
puts <<-EOS
Game begin.
You don't see this. -> (Gold is at
#{gold_door})
First. you choose door number
#{first_guess}.
I open door number
#{opened_door}.
So. You chnage your mind to door number
#{left_door}.

== You
#{result}. ==

EOS
gold_door == left_door ? 1 : 0
end

win = 0
loops = 30
loops.times do
win += play
end
puts "------------------"
puts "Play
#{loops}, win #{win}"

Related link from Roti

Monday, September 04, 2006

Antlr

ช่วงนี้มีโจทย์งาน ที่ต้องเขียน interpreter เอง
โดยตัว language ที่เขียน จะใช้สำหรับ generate รายงาน แบบ text
(ที่ออกทาง line printer หรือ dot matrix)

ตัว syntax ลอกแบบมาจาก Ingres report writer
(ที่ลอก ก็เพราะมี report เก่าหลายร้อย report
ที่อยากจะ switch database ไปใช้ database ตัวอื่น)
หน้าตา language ก็ประมาณนี้

.name xxxx
.query select name, salary from person
.header page
.pr '========================' .newline
.pr ' name salary .newline
.pr '========================' .newline
.header name
.tab 10
.print name
.newline
.detail
.tab 20
.print salary ("zzz,zzn.nn");
.newline
.footer page
.pr '========================' .newline
.pr ' total'
.tab 20
.pr sum(salary)
.newline


ตอนแรกก็ชั่งน้ำหนักก่อนเลย ว่าจะ implement ด้วยอะไรดี
ระหว่าง java กับ python
ตัว java นี่ของตายอยู่แล้ว
ส่วน python นี่ที่เลือก เพราะอยากเรียนรู้

สุดท้ายก็เลือกใช้ java เพราะว่ากรอบระยะเวลา
ที่อยากให้เสร็จภายใน 1 เดือน

tool ที่เลือกใช้ในส่วน parser ก็คือ Antlr
โดยข้อดีของการใช้ antlr ที่เห็นชัดๆ
ก็คือ meta syntax ของ antlr ที่ใช้เขียน lexer, parser, tree parser
มันเป็นตัวเดียวกัน ก็เลยง่ายในการเรียนรู้

เวลาเขียน parser ก็จะแยกเป็น 2 ขยัก
pass แรก ก็คือ compile language ให้เป็น AST (Abstract Syntax Tree) ก่อน
ขยักที่ 2 ก็คือตอน runtime
ซึ่งจะใช้ tree walker ท่องไปตาม AST ที่ได้จากข้อ 1

เริ่มแรกสุดผมก็ใช้วิธี top down
ทำ prototype ก่อน
define เฉพาะ gramma หลักๆที่อยากให้ prototype แสดงผลได้
หลังจากทำไปสัก 2 วัน ก็พบว่า
วิธีนี้มีข้อเสียมากกว่าข้อดี
ข้อดี ก็คือได้เห็นผลลัพท์ไว
ข้อเสีย ก็คือ gramma ของ feature ที่เพิ่มมาทีหลัง
มันจะ conflict กับ gramma ชุดแรก ได้ง่าย

ตอนนี้ก็เลยเปลี่ยนไปใช้วิธี bottom up
นั่ง define term ใล่จาก primitive datatype
ขึ้นมาเป็น expression ->ใล่ขึ้นมาเป็น statement
แล้วก็ใช้ junit เขียน test ประกบไปเรื่อยๆ
ทำให้ refactor ได้ง่ายขึ้น เพราะมี unit testing คอย proof ความถูกต้องอยู่

Related link from Roti

Form & Function

เห็น mk บ่นเรื่อง desinger ประเทศนี้
ก็เลยขอบ่นตามด้วย

เมื่อวานพาลูกนั่งรถเมล์ไปพิพิธภัณฑ์เด็ก
แต่เนื่องจากอากาศช่วงนี้เริ่มเข้าไกล้หน้าหนาวแล้ว
ฟ้าเปิดเต็มที่ ไม่มีเมฆมากวนใจ
เลยได้รับรู้ว่าหลังคาป้ายรถเมล์้เป็นพลาสติกใสสีฟ้านี่หว่า
สีสันไม่เลวเลย ฟ้าออกใสๆ ไม่เน่า หรือตุ่นเป็นพลาสติก recycle

สิ่งที่มาพร้อมกับความสวย ทันสมัย
ก็คือความร้อน
นั่งรอรถเมล์ตอนเกือบเที่ยงนี่มันจะสุกเอาได้

ผลงาน กทม. นี่รับประกันคุณภาพ
คราวก่อนก็มีประเด็นเรื่องป้ายโฆษณาบังสายตา
ทำให้มองไม่เห็นรถเมล์

มาคราวนี้ก็ใช้คนออกแบบที่พึ่งกลับจากอเมริกา
เลยยังไม่ชินกับสภาพอากาศเมืองไทย
(หรืออีกอย่าง ก็คือคนออกแบบที่ไม่เคยนั่งรถเมล์)

design ที่เป็น public แบบนี้
ไม่รู้ว่ามีกฎเกณฑ์การ approve design กันอย่างไรบ้าง

Related link from Roti