tapestry 5

ช่วงนี้ลูกหลับกลางวันเป็นเวลา เลยได้มีโอกาสลองเล่น tapestry 5
หลังจาก download tutorial มาทดสอบดูแล้ว
ก็พบ issue ที่น่าสนใจดังนี้
1. เดิม tapestry หรือ framework อื่นๆมักจะใช้ servlet
เป็นจุดตั้งต้น framework ของตัวเอง
แต่ tapestry 5 เปลี่ยนไปใช้ filter เป็นจุดเริ่มต้น

<filter>
  <filter-name>app</filter-name>
  <filter-class>org.apache.tapestry.TapestryFilter</filter-class>
</filter>

<filter-mapping>
  <filter-name>app</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>

น่าสนใจมาก ว่าการเปลี่ยนแบบนี้จะนำมาซึ่งข้อดีและข้อเสียอะไรบ้าง

2. การเปลี่ยน page เดิมจะใช้วิธี forward เป็นหลัก
แต่ใน tapestry5 จะใช้ redirect เป็นหลักแทน
ซึ่งข้อดี ก็คือการ handle กรณี user กด refresh จะทำได้ถูกต้องขึ้น

3. การเริ่มต้นสร้างโปรเจคใหม่ทำได้ง่ายมาก (อิทธิพลจาก rails)
ด้วยการ integrate กับ maven, ทำให้เรา create new project,
running project(start server) ได้ภายใน 2 command line.

4. loop การแก้ไข + ทดสอบ + แก้ไข + ทดสอบ ...
โดยไม่ต้อง restart server ทำได้เรียบร้อยดี
ยกเว้น case ที่เราเพิ่ม page ใหม่ๆ เข้าไปหลังจาก start server ไปแล้ว
ที่ต้องมีการ restart server ใหม่

5. ระยะเวลาการ start server เร็วกว่าเดิมแบบไม่เห็นฝุ่น
เดิมประมาณ 3-7 วินาที ของใหม่ หลัก 300 millisec
ที่เป็นเช่นนี้เพราะมีการ rewrite Ioc container ใหม่

6. เปลี่ยน Ioc(Inversion of Control) ไปใช้ java code + annotaion
แทน xml file, อันนี้แหล่ะตัวงงเลย เพราะผมใช้ xml ใน spring มาจนเคยตัวแล้ว

semaphore

ช่วงนี้คุณลูกบ้ารถไฟ คุณพ่อก็เลยต้องบ้าตามไปด้วย
หลังจากอ่านหนังสือประวัติรถไฟ คำแรกที่เห็นแล้วคุ้นตาอย่างยิ่งก็คือ
"semaphore" ซึ่งในทาง programming เราใช้ในการจัดลำดับการใช้ทรัพยากรร่วมกัน
ก็เลยทำให้เกิดความสงสัยว่า ศัพท์คำนี้, พวกชาวคอมพิวเตอร์ไปยืมแนวคิดมาจากไหนอย่างไร

ลองเปิด dictionary ดู ก็พบว่า
semaphore มีรากศัทพ์มาจากสองคำคือ
sema -> sign
phoros -> carrying
รวมกันแล้ว ก็คือ system ที่ใช้ส่งข้อมูลระหว่างกัน โดยอาศัยการมองเห็นเป็นสำคัญ

ใน wikipedia เขาเล่าว่า ฝรั่งเศษ เป็นคนเริ่มใช้ก่อน
โดยเริ่มนำมาใช้อย่างจริงจังในช่วงปี 1790-1795
ซึ่งเป็นช่วงที่เกิดการปฎิวัติ (French Revolution)
โดยเขาจะสร้างสถานี (staion) ใล่กันไป
แต่ละสถานีอยู่ห่างในระยะที่มองเห็นกันได้
เมื่อมี information ที่จะส่ง สถานีที่ส่งก็จะปรับ sign (แล้วแต่ว่าเลือกออกแบบ sign ไว้อย่างไร)
ของตัวเอง, สถานีถัดไปเมื่อมองเห็นก็จะปรับของตัวเองตาม
copy กันเป็นทอดๆไป จนกว่าจะถึงปลายทาง
(จะเห็นว่ามันเหมือนวิธีส่งโทรเลขเลย
ดังนั้นจึงมีชื่อเรียกอีกอย่างว่า optical telegraph)

ลองดูตัวอย่าง sign บ้าง
sign แบบแรกที่เราคุ้นเคย ก็คือสัญญาณธง


ส่วนพวก รถไฟ,
ในยุครถจักรไอน้ำ
เมื่อจำนวนรางที่เชื่อมต่อกันมีมากขึ้น
ปริมาณขบวนรถไฟที่วิ่งมีมากขึ้น
ก็เลยต้องหาวิธีการสื่อสารระหว่างคนขับรถไฟ กับนายสถานีขึ้นมา
เพื่อให้สามารถควบคุมการวิ่งของรถไฟให้มีประสิทธิภาพสูงสุด
รวมทั้งป้องกันไม่ให้เกิดอุบัติเหตุ
ก็เลยมีการ apply นำ semaphore มาใช้


Note: รูปเพิ่มเติมใน flickr

ดูแล้ว semaphore ที่ทาง computer นำมาใช้
จะมาจากแนวพวก semaphore ที่ใช้ในวงการรถไฟ
เนื่องจากเป็นเรื่องของการจัดสรรทรัพยากรที่มีอยู่จำกัด
(ทรัพยากรที่จำกัดของรถไฟ ก็คือราง)
ซึ่งเป็นปัญหาพวก concurrency แบบเดียวกัน

unit_of_work

ใน rails เวลาเราเขียน action ส่วนที่เกี่ยวกับการ save, update
หน้าตาของ code ตรงนั้นส่วนใหญ่จะยึดตามแบบนี้

  def create
    @role = Role.new(params[:role])
    if @role.save
      flash[:notice] = 'Role was successfully created.'
      redirect_to :action => 'list'
    else
      render :action => 'new'
    end
  end

ซึ่งดูแล้วก็รู้เรื่องดี, แต่สำหรับผมเวลาเขียน code ตรงส่วนนี้ทีไรมันรู้สึกขัดๆ

Obie Fernandez ก็คงรู้สึกแบบเดียวกัน
แต่เขาหาวิธีแก้ไขได้เนียนดี
โดยเขาเปลี่ยนวิธี save เป็นแบบนี้แทน

  def create
    case unit_of_work do
      @role = Role.new(params[:role])
    end
    
    when Success
      redirect_to :action => 'list'
      
    when ValidationError
      render :action => 'new'      
    end    
  end

เป็นการเอา block + case statement มา combine กันได้สวยดี
โดยตัว unit_of_work เป็น method ที่รับ block เข้าไป