new_user_session GET    /users/sign_in(.:format)          {:action=>"new", :controller=>"devise/sessions"}
             user_session POST   /users/sign_in(.:format)          {:action=>"create", :controller=>"devise/sessions"}
     destroy_user_session GET    /users/sign_out(.:format)         {:action=>"destroy", :controller=>"devise/sessions"}
            user_password POST   /users/password(.:format)         {:action=>"create", :controller=>"devise/passwords"}
        new_user_password GET    /users/password/new(.:format)     {:action=>"new", :controller=>"devise/passwords"}
       edit_user_password GET    /users/password/edit(.:format)    {:action=>"edit", :controller=>"devise/passwords"}
                          PUT    /users/password(.:format)         {:action=>"update", :controller=>"devise/passwords"}
 cancel_user_registration GET    /users/cancel(.:format)           {:action=>"cancel", :controller=>"devise/registrations"}
        user_registration POST   /users(.:format)                  {:action=>"create", :controller=>"devise/registrations"}
    new_user_registration GET    /users/sign_up(.:format)          {:action=>"new", :controller=>"devise/registrations"}
   edit_user_registration GET    /users/edit(.:format)             {:action=>"edit", :controller=>"devise/registrations"}
                          PUT    /users(.:format)                  {:action=>"update", :controller=>"devise/registrations"}
                          DELETE /users(.:format)                  {:action=>"destroy", :controller=>"devise/registrations"}
        user_confirmation POST   /users/confirmation(.:format)     {:action=>"create", :controller=>"devise/confirmations"}
    new_user_confirmation GET    /users/confirmation/new(.:format) {:action=>"new", :controller=>"devise/confirmations"}
                          GET    /users/confirmation(.:format)     {:action=>"show", :controller=>"devise/confirmations"}

As you can see, all of the routes are defined under /users path. So, I’ve modified my devise route block to this:

devise_for :users, :skip => [:registrations, :sessions] do
  # devise/registrations
  get 'signup' => 'devise/registrations#new', :as => :new_user_registration
  post 'signup' => 'devise/registrations#create', :as => :user_registration
  get 'users/cancel' => 'devise/registrations#cancel', :as => :cancel_user_registration
  get 'users/edit' => 'devise/registrations#edit', :as => :edit_user_registration
  put 'users' => 'devise/registrations#update'
  delete 'users/cancel' => 'devise/registrations#destroy'
 
  # devise/sessions
  get 'signin' => 'devise/sessions#new', :as => :new_user_session
  post 'signin' => 'devise/sessions#create', :as => :user_session
  get 'signout' => 'devise/sessions#destroy', :as => :destroy_user_session
end

Which will yield these routes:

    new_user_registration GET    /signup(.:format)                 {:action=>"new", :controller=>"devise/registrations"}
        user_registration POST   /signup(.:format)                 {:action=>"create", :controller=>"devise/registrations"}
 cancel_user_registration GET    /users/cancel(.:format)           {:controller=>"devise/registrations", :action=>"cancel"}
   edit_user_registration GET    /users/edit(.:format)             {:controller=>"devise/registrations", :action=>"edit"}
                    users PUT    /users(.:format)                  {:action=>"update", :controller=>"devise/registrations"}
             users_cancel DELETE /users/cancel(.:format)           {:controller=>"devise/registrations", :action=>"destroy"}
         new_user_session GET    /signin(.:format)                 {:action=>"new", :controller=>"devise/sessions"}
             user_session POST   /signin(.:format)                 {:action=>"create", :controller=>"devise/sessions"}
     destroy_user_session GET    /signout(.:format)                {:action=>"destroy", :controller=>"devise/sessions"}
            user_password POST   /users/password(.:format)         {:action=>"create", :controller=>"devise/passwords"}
        new_user_password GET    /users/password/new(.:format)     {:action=>"new", :controller=>"devise/passwords"}
       edit_user_password GET    /users/password/edit(.:format)    {:action=>"edit", :controller=>"devise/passwords"}
                          PUT    /users/password(.:format)         {:action=>"update", :controller=>"devise/passwords"}
        user_confirmation POST   /users/confirmation(.:format)     {:action=>"create", :controller=>"devise/confirmations"}
    new_user_confirmation GET    /users/confirmation/new(.:format) {:action=>"new", :controller=>"devise/confirmations"}
                          GET    /users/confirmation(.:format)     {:action=>"show", :controller=>"devise/confirmations"}

I think my new routes is much better. For example, I think user would prefer a path to sign in page to be /signin than /users/sign_in, as it more memorable.

I hope this post would inspire you more about customize Devise’s routes to fit your need.

That statement really apply to myself. I think I’m a good thinker, but somehow lack of the execution. I wasn’t notice anything about it at all until I reach a point in my life, which is “Getting a job.”

Nowadays, being a programmer since Grade 10 doesn’t really count if you don’t have a project that you can show off, or at least any open source project or contribution to the community. You need something to show off to that company that you’re capable, and skilled.

If you have great idea, make it real, or make it happen. Don’t just leave it die in your head or in your notebook as I do.

If you’re writing a web application and let someone to use it, you actually have to be on it too. Make yourself to become an user of the site, and use it generally as everyday user.

We usually say that nobody knows the problem more than user, so that’s why you need to be in the user role, or get in their shoes, to feel the application the way those user are facing everyday.

Eating your own dog food, or using what you’ve made, is a good thing. Trust me. That’s why I believe Google uses Gmail, 37 Signals using their Basecamp, Highrise and Campfire, and Microsoft uses IE mainly in their company (whaa??)

Try it, and let me know if it helps you to understand the pain your users have to take everyday or not, if any.

แต่ถ้ามองย้อนกลับไปยัง iPhone 3GS ในประเทศไทย ถ้าจำไม่ผิดจะเห็นได้ว่า Truemove นำเข้ามาขายในเดือนสิงหาคม ส่วน DTAC นั้น ตามเข้ามาขายในช่วงของต้นปี 2553 ซึ่งล้าหลังจาก Truemove ไปประมาณครึ่งปี (และถือว่าช้ากว่าผู้ให้บริการรายแรกไป 1 ปี)

โดยส่วนตัวแล้ว ผมคิดว่า DTAC ใช้เวลาในการตัดสินใจลงทุนเอา iPhone เข้ามาขายนั้น “นานเกินไป” ครับ แต่เนื่องจาก DTAC ได้ภาษีในการที่เครือข่าย EDGE ดีกว่า Truemove จึงทำให้มียอดขายดีในระดับหนึ่ง เพราะคนมั่นใจในเครือข่าย (ผมว่าโฆษณา ก็ช่วยสร้างภาพให้ดีขึ้นส่วนหนึ่งด้วยล่ะครับ)

แต่ถามว่า แล้วจะเป็นอย่างไรต่อไป ผมว่าน่าสนใจครับ

ผมว่าหลังจาก iPhone 4th Generation เปิดตัวแล้ว กระแสของการซื้อ iPhone คงจะบูมขึ้นมาอีกครั้งหนึ่ง เพราะฉะนั้นผมคิดว่าถ้าใครสามารถคุยกับ Apple แล้วนำเข้ามาขายได้เร็วที่สุด แน่นอนว่าฝ่ายนั้นคงจะชนะแน่นอนครับ

แต่ว่า ถ้าทั้งสองฝ่ายเปิดตัวพร้อมกัน (ซึ่งส่วนใหญ่ หลายๆ ประเทศจะเป็นอย่างนี้) ผมว่าคราวนี้คงจะเป็นฝ่าย DTAC ที่ชนะครับ เพราะผมเชื่อว่ามีหลายๆ คนคงเลือก DTAC แทนที่จะเป็น Truemove เพราะเรื่องของคุณภาพของ EDGE ครับ

แต่ถ้า DTAC ขายเครื่องได้มากกว่าจริง สถานการณ์จะเริ่มพลิกแล้วล่ะครับ!

จากวันที่ขายเครื่องวันแรก ผมคิดว่าไม่เกิน 2-3 เดือนนั้น DTAC คงจะมีปัญหาเรื่องของช่องสัญญาณของการให้บริการ Internet แน่นอนครับ หากไม่มีการจัดสรรช่องสัญญาณให้ดี และไม่มีการเพิ่ม bandwidth

ถามว่าทำไม? เพราะว่าเอาเข้าจริงแล้ว iPhone นี่กิน bandwidth มากกว่าที่คิดนะครับ อย่าง AT&T ยังออกมาบอกเลยว่า 40% ของ traffic ทั้งหมด เป็นของ iPhone ซึ่งทำให้ระบบแทบที่จะรับไม่ไหว (แล้วก็โดนด่าแหลกลาญครับ แหะๆๆ)

เพราะฉะนั้นถ้าไม่มีอะไรเปลี่ยนแปลง ในตอนนี้ระบบของ DTAC ที่ใช้ APN เดียวรวมกันนั่นคือ ‘internet’ คงจะมีโอกาสล่มเป็นแน่แท้ครับ แล้วผมก็หวังว่าหลังจากที่มีการเปิดตัว iPhone พร้อม package ใหม่ คงจะมีการแบ่งแยก APN ของ iPhone ให้ชัดเจนเลย จะทำให้ระบบเบามากกว่านี้ครับ

แต่ว่าอย่างไรก็ตาม ผมว่าถ้า AIS เข้ามาเล่นตามกระแส iPhone ด้วยนี่ … ผมว่า DTAC คงจะหืดขึ้นคอ ส่วน Truemove นี่คงปลิวกระเด็นเลยล่ะครับ เพราะอย่างไรก็ตามความเสถียรของ internet ของ AIS นั้นก็ยังคงดีกว่ามากๆ แล้วยิ่งการที่มีฐานลูกค้าเดิมหนุนหลังอยู่แล้ว ถ้า AIS เปิดตัว iPhone มานี่ สะท้านแน่นอนล่ะครับ

เรามาดูกันเถอะครับว่าจะเป็นอย่างไรต่อไป อย่าลืมครับว่า … “ใครเข้ามาก่อนชนะ มาพร้อมกันใครเน็ตดีชนะ แต่ถ้า AIS มา เจ้ามือกินเรียบ” แน่นอนครับ

ปล. ผมเป็นผู้ใช้ DTAC ครับ ปัจจุบันผมรู้สึกว่าเน็ตห่วยลงได้ใจครับ -_-’
ปปล. ผมไม่เอา 3G เข้ามาเป็นตัวตัดสิน เพราะว่า Truemove “น่าจะ” โดนยึด 3G, TOT ไม่น่าจะเอา iPhone เข้ามาขาย และประเทศเราก็จะไป LTE (3.9G) ซึ่ง iPhone ก็ไม่น่าจะรองรับได้ … พอมองการณ์ไกลก็ล่อซะเหยียดไม่ถึงเลยนะ -_-”

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

ปัจจุบันนี้ ระบบขนส่งมวลชนในกรุงเทพนั้น ต่างคนก็ต่างเก็บค่าใช้บริการในระบบที่ต่างกัน กล่าวคือ BTS ใช้บัตรแม่เหล็กกับ RFID (Smart Pass) ส่วน MRT นั้นใช้แต่ RFID (Token + Value Card) แต่รถเมล์นั้นกลับรับแต่เงินสด ซึ่งจะเห็นได้ว่าหากเราเดินทางในกรุงเทพนั้น ถ้าต้องขึ้นรถต่อรถไฟฟ้าแล้วต่อใต้ดิน เราต้องพกทั้งเงินสดและบัตร RFID สองใบ ซึ่งมันก็ดูไม่สะดวกเอาซะเลย

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

แล้วจะพัฒนาระบบได้อย่างไร

ตรงนี้ผมแยกเป็นสองส่วนครับ คือส่วนของระบบการเติมเงิน และระบบของการตัดเงิน

การเติมเงิน

ปัญหาของเรื่องนี้คือ ไม่มีใครหรอกครับที่ไม่อยากให้เงินของเราไปอยู่ในมือของบริษัทใดบริษัทหนึ่ง เพราะฉะนั้นผมว่าตรงนี้ สิ่งที่น่าจะเป็นไปได้มากที่สุดคือการมารวมตัวกันของ BMTA/BTS และ BMCL จัดตั้งบริษัทที่มีหน้าที่จัดการในส่วนของการเติมเงิน หรือพูดง่ายๆ ก็เป็นผู้ถือเงินนั่นล่ะครับ

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

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

การตัดเงิน

สำหรับ MRT และ BTS นั้น ถ้าระบบร่วมของเราใช้ตั๋วโดยสารแบบ RFID ในคลื่นความถี่เดียวกัน ผมว่าสิ่งที่เหลืออย่างเดียวคือการลิงค์กันระหว่างระบบและดึงจำนวนเงินคงเหลือมาจากฐานข้อมูลกลางครับ (ซึ่งตรงนี้เข้าใจว่า MRT/BTS กำลังเชื่อมกันอยู่ และบอกว่าจะร่วมกันได้ภายในสิ้นปี 2554 ครับ)

แต่ในส่วนของรถเมล์นั้น คิดว่าคงจะยากแน่นอนครับ กับการที่จะเอาบัตร RFID ไปใช้ แต่ผมคิดว่ามันมีอยู่ 2 วิธีครับ ในการติดตั้ง

1. ติดตั้งไว้ที่เสาบริเวณประตูขึ้นลง

เอาเข้าจริง ทุกประเทศที่เขาใช้บัตรเขาเป็นอย่างนี้หมดครับ … แต่ว่าคิดว่าทาง ขสมก. คงไม่ไว้ใจคนไทยแน่นอน (เพื่อนผมยังเคยขึ้นรถเมล์ฟรี แล้วมาเล่าให้ฟังเลย ..) เพราะฉะนั้นก็คงเหลือ

2. ติดไว้ที่กระป๋องเก็บค่าโดยสาร

ไอ้ที่กระเป๋ารถเมล์ชอบเขย่า แกร่กๆๆ นั่นแหละครับ ติดไปด้านบนหรือด้านล่าง ข้างในหลอดขนาดยาวสักประมาณ 10cm คงจะได้ มี simcard module และ removable battery พร้อมสรรพ สำหรับการส่งข้อมูลผ่านทาง EDGE (หรือ 3G พับผ่า !!) ไปยัง server แม่ข่าย เพื่อทำการเรียกยอดเงินและตัดเงิน

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

สำหรับเรื่องของการตัดเงินนี่ ถ้าเป็นที่เมือง Boston (ที่ใช้ Charlie Ticket) เขาจะใช้ Kiosk คล้ายๆ กันในทุกๆ ที่ครับ คือมีให้สอดบัตรสำหรับบัตรชั่วคราว และมีที่แตะ RFID สำหรับบัตรรายเดิน/บัตรเติมเงิน ผมคิดว่าประเทศเรามาไกลแล้วสำหรับ RFID เพราะฉะนั้นมีแต่เครื่อง RFID น่าจะดีที่สุดครับ

รู้สึกว่าจะฝันเฟื่องอีกแล้ว แต่ผมอยากให้เป็นจริง จริงๆ นะครับ เพราะจะได้เลิกพกบัตร 2 ใบ แล้วก็เลิกพกเหรียญย่อยๆ ไว้จ่ายรถเมล์สักที

ความผิดพลาดของ Easy Pass (ต่อ)

เมื่อตอนที่ 2 ผมได้กล่าวเอาไว้ว่าความผิดพลาดตรงนี้ มันมีทั้งในส่วนของตัวอุปกรณ์ Easy Pass, ระบบจัดการเงิน, การเข้าใช้บริการ และการส่งเสริมการใช้งานครับ วันนี้จะมาเขียนให้ครบครับว่ามีอะไรอีก

3. การเข้าใช้บริการ

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

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

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

ส่วนเรื่องสุดท้ายคือตำแหน่งของตัวอ่านเขียนข้อมูลครับ ถ้าได้ลองดู VDO ของระบบ ETC ในญี่ปุ่นเมื่อตอนที่แล้วนั้น จะเห็นได้ว่าตัวอ่านเขียนของเขานั้นจะถอยร่นลงมาจากตูผ่านทาง ทำให้ระยะทางระหว่างเครื่องอ่านเขียนกับที่กั้นนั้นมากขึ้น และทำให้ที่กั้นนั้นเปิดให้บริการทันกับความเร็วที่เหมาะสมในการใช้งาน (ประมาณ 30 กม./ชม.) เพราะที่เห็นอยู่ปัจจุบันนี้ผู้ใช้งานจะต้องขับรถเข้าไป “จอดรอ” ให้ที่กั้นเปิด … มันทำให้รถชะลอตัวมากขึ้นน่ะครับ

4. การส่งเสริมการใช้งาน

หลังจากที่เปิดให้บริการมา ทาง EXAT ได้มีโปรโมชั่นออกมาสองตัว นั่นคือการลดค่ามัดจำบัตรเหลือ 500 บาท และลดค่าผ่านทางให้ 5% สำหรับการเติมเงินก่อนวันที่ 28 กุมภาพันธ์

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

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

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

ก่อนที่จะสายเกินแก้

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

1. จัดระเบียบช่อง Easy Pass ใหม่ ให้อยู่ในเลนที่สามารถเข้าใช้งานได้สะดวกขึ้น ไม่ต้องไปติดตามรถที่จ่ายเงินโดยระบบปกติ
2. เพิ่มช่องทางแบบ “Easy Pass และเงินสด” เอาให้ได้ 50% ของด่านใหญ่ๆ และให้ได้ 100% ของด่านที่มีช่องทาง 2-3 ช่องครับ
3. เพิ่มความยาวของช่อง Easy Pass เอาตัว Sensor ถอยออกมาให้ได้ระยะทางพอที่ที่กั้นจะเปิดให้บริการทันกับความเร็วของรถได้
4. มีระบบการติดลบเงินค่าผ่านทาง โดยไปหักเงินจากค่ามัดจำของบัตรได้
5. เพิ่มจุดเติมเงิน Easy Pass ในที่ต่างๆ เช่น 7-11, Counter Service, ผ่านช่องทางของ True Money เพื่อให้สามารถเติมค่าผ่านทางได้ล่วงหน้า ทุกที่
6. จัดโปรโมชั่นลดราคาค่าผ่านทาง 1%-5% ให้สำหรับผู้ใช้งาน Easy Pass เพื่อให้ได้รับสิทธิประโยชน์เหมือนกับการใช้คูปอง และถือว่าเป็นการส่งเสริมการใช้งาน เพื่อลดปริมาณรถที่มาแออัดบริเวณหน้าด่านเก็บเงิน
7. มีศูนย์บริการติดตั้ง Easy Pass พร้อมทั้งเครื่องมือตรวจสอบว่าสามารถอ่านเครื่อง Easy Pass ได้อย่างถูกต้องในตำแหน่งที่ติดตั้ง
8. ทำแบบที่ญี่ปุ่น คือประสานงานกับค่ายรถ ติดเครื่อง ETC ให้กับรถยนต์ใหม่ที่ขายในกรุงเทพ เพื่อเพิ่มผู้ใช้งานใหม่ๆ

สุดท้ายที่อยากฝากไว้

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

ก่อนที่จะสายไป ผมเลยอยากให้ทาง EXAT ปรับปรุงระบบต่างๆ ให้ดีขึ้นมากกว่านี้ ก่อนที่ผู้ใช้ทางพิเศษจะ “ขยาด” กับระบบ ETC/Easy Pass แล้วทำให้การลงทุนที่ทำไปนั้นล้มเหลวไปครับ เพราะเอาเข้าจริงแล้วระบบ ETC จะมีประโยชน์มากที่สุดก็ต่อเมื่อผู้ใช้งานมากกว่า 50% นั้น หันไปใช้เครื่อง ETC แทนการจ่ายเงินค่าผ่านทางด้วยเงินสดครับ

หลังจากที่รู้จักกันไปแล้วว่าระบบ ETC และ Easy Pass นั้นคืออะไร คราวนี้เราลองมาดูต่อกันครับว่าระบบ ETC ที่ดีนั้นมันควรจะเป็นอย่างไร และทำไมผมถึงบอกว่า Easy Pass นั้นเป็นระบบแห่งความผิดพลาด

ระบบ ETC ของประเทศญี่ปุ่น

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

เอาเป็นว่า ถ้าอยากรู้ว่าระบบ ETC ที่ญี่ปุ่นนั้นเป็นอย่างไร ลองแว่บไปดู VDO ตัวนี้ดูครับ: ETC in Japan

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

เพราะฉะนั้นจุดมุ่งหมายของระบบ ETC แน่นอนว่าเป็นการที่ทำให้ผู้ที่ใช้งานทางพิเศษสามารถชำระค่าผ่านทางได้ง่ายขึ้น ไม่จำเป็นต้องเตรียมเงินค่าผ่านทาง (ตัดปัญหา “รถคันหน้าแบงค์พัน”) โดยที่ทางญี่ปุ่นนั้นก็มีการรณรงค์ให้รถส่วนใหญ่นั้นใช้บริการ ETC แทน เพื่อที่จะได้ลดปริมาณรถที่ไปคับคั่งอยู่ที่หน้าด่านเก็บเงิน และเป็นการเพิ่มความสะดวกให้ผู้ใช้ทางพิเศษครับ

แล้วทำไมผมถึงบอกว่า Easy Pass ผิดพลาด?

คำตอบส่วนใหญ่ของคำถามนี้ สามารถหาได้จากเว็บบอร์ดของ EXAT เองครับ

ความผิดพลาดตรงนี้ มันมีทั้งในส่วนของตัวอุปกรณ์ Easy Pass, ระบบจัดการเงิน, การเข้าใช้บริการ และการส่งเสริมการใช้งานครับ

1. ความผิดพลาดในส่วนของตัวอุปกรณ์

Easy Pass นั้นประกอบไปด้วยสองส่วน นั่นคือส่วนของตัว RFID Tag และส่วนของบัตรที่ใช้เติมเงิน

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

คำถามคือ นี่เท่ากับว่ากลับไปซ้ำรอยในเรื่องของปัญหาการใช้ TAG ที่เครื่องอ่านมันหา TAG ไม่เจอ อีกแล้วใช่ไหมครับ?

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

ถ้าลองดูในเว็บบอร์ดจะเห็นว่ามีแต่คำร้องเรียนในเรื่องของการที่ระบบนั้น “ตัดเงินเบิ้ล” หรือบางคนก็ “ระบบไม่ตัดเงิน” ก็มีครับ ซึ่งเป็นปัญหาของการที่ต้องทั้งอ่านและเขียนข้อมูลลงบนบัตร Easy Pass ครับ

2. ระบบการจัดการเงิน

ระบบของ Easy Pass นั้น จริงๆ แล้วก็คล้ายคลึงกับระบบของบัตรรถไฟฟ้า BTS นะครับ นั่นก็คือต้องมีการเติมเงินเอาไว้ก่อน แล้วมีการหักค่่าผ่านทางออกไปเรื่อยๆ ซึ่งแน่นอนว่าต้องมีปัญหาในเรื่องของ “เงินไม่พอจ่าย” แน่ๆ ครับ

ในระบบของ BTS/MRT เขาแก้ปัญหาในเรื่องของเงินไม่พอจ่าย โดยการเรียกเก็บเงินค่ามัดจำบัตร 50 บาทไว้ตั้งแต่เปิดบัตร ซึ่งตรงนี้ถ้าเงินที่เติมไว้ในบัตรไม่พอจ่าย ระบบก็จะไปหักออกจากค่ามัดจำที่ได้เติมเอาไว้ ทำให้ในเวลาที่ “เร่งรีบ” จริงๆ ถึงเงินในบัตรเหลือ 5 บาท ผมก็ยังจะสามารถเดินเข้าประตูอัตโนมัติได้

คราวนี้กลับไปมองในระบบ Easy Pass คำถามคือถ้าเงินในบัตรของผมไม่เพียงพอสำหรับการจ่ายค่าผ่านทาง แล้วผมต้องทำอย่างไรหรือครับ?

[คู่มือการใช้บริการ หน้า 12]

6. การผ่านช่องอัตโนมัติจะต้องมียอดเงินคงเหลือในบัญชีสำรองค่าผ่านทางเพียงพอที่จะผ่านช่องอัตโนมัติตามที่การทางพิเศษแห่งประเทศไทยกำหนด

7. หากยอดเงินในบัญชีสำรองค่าผ่านทางไม่มี บัตร Easy Pass จะถูกระงับการใช้ (Black List) จนกว่าผู้ขอใช้บริการจะเติมเงินลงในบัญชีสำรองค่าผ่านทาง

[หน้า 19]

4.3 หากท่านได้ยินเสียง Beep สอง (2) ครั้งจากบัตร Easy Pass [..] หมายถึงบัตร Easy Pass ไม่อยู่ในสภาวะที่ใช้งานได้ [..] กรณีนี้ท่านจะต้องถอยรถยนต์ออกจากช่องทางเพื่อใช้บริการช่องเก็บค่าผ่านทางแบบเงินสดแทน ท่านสามารถติดต่อเจ้าหน้าที่ได้จากอุปกรณ์สื่อสาร

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

แล้วนี่มันจะช่วยเรื่องการจราจรตรงไหนครับ? ถ้ารถคันหน้าผมเงินมันหมด ปล่อยผ่านไปสักครั้งแล้วติดลบเงินในบัญชีจะไม่ได้เลยหรือครับ? เท่ากับว่ารถทั้งแถวนั้นก็ต้องถอยหลัง เพื่อที่ให้รถคันที่มีปัญหานั้นออกมาจากช่องอัตโนมัติ … แย่กว่าการจ่ายเงินโดยใช้เงินสดอีกนะครับนี่

อย่าลืมครับว่าถ้าเป็น BTS/MRT เงินหมดเราเดินแทรกออกไปเติมเงินได้ง่ายๆ … มันไม่เหมือนกันครับ พื้นที่หน้าด่านมันมีจำกัดมากกว่านั้น …

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

เขียนไปเขียนมารู้สึกจะมันส์ไปหน่อย ยกยอดไปต่อตอนที่สามวันพรุ่งนี้นะครับ

ระบบ ETC คืออะไร

ระบบ ETC (Electronic Toll Collection) คือระบบที่ใช้ในการเก็บค่าผ่านทางพิเศษอัตโนมัติ เพื่อเป็นการแก้ปัญหาการที่ต้องมาต่อแถวจ่ายเงินค่าผ่านทาง ซึ่งต้องเสียเวลาทั้งการรับเงินสด และการทอนเงิน

เอาเข้าจริงแล้วระบบนี้ในกรุงเทพเรามีมานานแล้วครับ โดยที่เมื่อก่อนเราจะเรียกมันว่า TAG ทางด่วน ซึ่งใครที่พอมีอายุเช่นผมก็จะจำได้ว่ามันเกิดมาเพื่อให้ใช้กับทางด่วนขั้นที่หนึ่ง (ดินแดง-บางนา-ดาวคะนอง) และมีปัญหาในเรื่องของสัมปทาน (ถ้าผมจำไม่ผิดนะครับ) ทำให้ไม่สามารถขยายการให้บริการมายังทางด่วนขั้นที่สองได้ ทำให้สุดท้ายแล้วการทางพิเศษฯ (ชื่อเดิมของ EXAT) ต้องทำการพับระบบเดิมกลับไป แล้วเริ่มต้นทำระบบใหม่อีกครั้ง

การมาของ Easy Pass

Easy Pass เปิดตัวเองมาได้อย่างสวยหรูในกลางปี 2552 กับความรู้สึกที่ทำให้ผู้ใช้ทางพิเศษอยู่ทุกๆ วัน รู้สึกว่านี่เป็นทางเลือกที่ดี เพราะนอกจากความสามารถในการใช้งานบนทางด่วนขั้นที่หนึ่งแล้ว ยังรวมไปถึงการใช้งานบนทางด่วนสายใหม่ๆ เช่น รามอินทรา-อาจนรงค์ และทางด่วนขั้นที่สองอีกด้วย พร้อมทั้งคำกล่าวที่บอกว่าจะให้บริการบนทางด่วนขั้นที่หนึ่งภายในธันวาคม 2552 และทางด่วนขั้นที่สองภายในปี 2553

แต่สุดท้ายแล้วก็เกิดอาการเลื่อนในการให้บริการ ทำให้การเปิดใช้งานของ Easy Pass ต้องล่าช้าไปจนถึงสิ้นเดือน ม.ค. 2553 แต่สุดท้ายก็เปิดให้บริการจนได้ครับ

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

สุดท้ายแล้วก็เลยตัดสินใจ เปลี่ยน Package EDGE/GPRS เป็น Unlimited 999 บาทซะ (ของ DTAC ครับ) เพราะว่า DTAC มันไม่มีแบบที่เหมา Kb/Mb เยอะๆ แบบ AIS

เนื่องจาก cost ของ EDGE/GPRS จะพุ่ง ก็เลยต้องหา Package ที่ลดค่าโทรมา เลยทำการ Analyze การใช้โทรศัพท์ตัวเอง ปรากฎว่า ..

(ค่าโทรข้างล่าง ต้องบวกไปอีก 299 นะครับ เป็นค่า Package)

อุแม่เจ้า เพิ่งเห็นว่าเราใช้โทรศัพท์แค่เดือนนึงสูงสุด 124 นาทีเอง … นี่ถือว่าน้อยมากนะเนี่ย (เพราะส่วนใหญ่ชอบส่ง SMS มากกว่า -*-)

สุดท้ายแล้ว ก็เลยทำการเปลี่ยน Package เป็นดังนี้

- โทรมันจิงดิ 200 นาที ในเครือข่าย/200 นาทีนอกเครือข่าย 250 บาท (เล็กที่สุด + คุ้มที่สุดแล้ว)
- SMS 110 ข้อความ 79 บาท (คุ้มๆ)
- EDGE/GPRS Unlimited Monthly 999 บาท

ตกๆ แล้ว เดือนนึงจะจ่ายประมาณ 1500 บาท … ไม่รู้แม่จะว่ามั้ย หุหุ (แม่ยังจ่ายค่ามือถือให้อยู่ครับ)

หวังว่าสิ้นเดือนหน้า DTAC จะมาพร้อมกับ Package GPRS ราคาประหยัดลงหน่อยนะครับ สัก 599 กำลังดี … เข้าใจว่าระบบเร็ว แรง แต่ขอราคาถูกๆ ด้วยได้ไหมครับ T_T

(ถึงไม่เอา iPhone เข้ามาขาย แต่เห็นใจแล้วลดราคาให้คนใช้ iPhone หน่อยเต๊อะ …)

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

แต่สิ่งที่ควรทำคือ พอเว็บไซต์ของเราออกสู้สาธารณชนแล้ว ต้องปิดมันซะครับ!

เหตุผลคือ มันจะทำให้คนที่ต้องการจะเข้ามาแฮกเว็บไซต์ของเราเนี่ย สามารถดูได้หมดเลยว่าโค้ดของเรานั้นอยู่ที่ directory ไหน และบางทีก็จะเห็นเลยว่า table ที่เราใช้เก็บข้อมูลนั้นคืออะไร

แล้วที่แย่ไปกว่านั้นคือ ถ้าเราไม่ได้กันโค้ด SQL Injection อีก .. ตายครับตาย เว็บคุณจะโดนแฮกไม่รู้ตัว อยู่ดีๆ ใครก็เข้ามาเป็น admin ก็ไม่รู้

ค้นหาวิธีการไม่แสดง log แต่ให้ไปเก็บไว้ที่ไฟล์ๆ หนึ่งทาง Google เอาดูนะครับ แต่ว่าอย่าลืมว่าตำแหน่งที่จะเก็บ log file ต้องอยู่นอก htdocs ด้วยนะครับ ไม่เช่นนั้นก็อาจจะเจอปัญหาคนมาเปิดดูได้อยู่ดี

อย่าลืมครับ ไม่แสดง log และเก็บ log ในที่ปลอดภัย