มาช่วยกันนำเสนอเทคโนโลยี เพื่อเลือกใช้ใน Project

[Dreamer]

จากความต้องการของผู้ใช้ ต้องการระบบบัญชี ที่มีความยืดหยุ่น เป็นมาตรฐาน
เป็น web application แยกเป็น module ที่สามารถ plug in
เนื่องจากว่าระบบบัญชีเป็นระบบที่มีความซับซ้อน
และมักจะมีลักษณะตายตัวเฉพาะบริษัทใดๆ ทั้งๆ
ที่ก็เป็นระบบที่ไม่มีความเปลี่ยนแปลงในหลักการมานานแล้ว
การจะสร้างระบบบัญชีที่เป็นมาตรฐานนั้นอาจต้องปรับปรุงโครงสร้างให้มีความยืดหยุ่นสูงสุด
และควรมี model
ต้นแบบที่สามารถครอบคลุมความต้องการของผู้ใช้ได้แทบทั้งหมด
ซึ่งการเขียนโครงสร้างนี้ให้กับฐานข้อมูลมักจะกลายเป็นการผูกติดกับฐานข้อมูลนั้นไป
หากเป็นไปได้ไม่ควรผูกติดเข้ากับ ฐานข้อมูลใดๆ
แต่สามารถใช้กับฐานข้อมูลได้หลายชนิดขึ้นกับผู้ใช้

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

- ภาษา Java สำหรับสร้าง business process
- - เป็นภาษาที่มีความยืดหยุ่นสูงสุด สามารถวิ่งได้ทั้งบน Windows,
Linux, Mc ใช้ทำงานได้ทั้งบนมือถือ บนคอมพิวเตอร์ทั่วไป และบน Server
ขนาดใหญ่
- - เป็นภาษาที่ support ทั้งการเขียนโปรแกรมธรรมดา และการเขียน server
ต่างๆ โดยมี API หรือ module ที่ใช้เฉพาะงาน support อยู่เป็นจำนวนมาก
- - เป็นภาษาที่แยกงานออกเป็นชิ้นๆ (class)
ที่สามารถนำมาประกอบเรียกใช้งานรวมกันในภายหลัง
ทำให้ง่ายต่อการแก้ไขข้อผิดพลาดเฉพาะจุด
และสามารถนำมาประกอบต่อยอดการพัฒนาขึ้นไปได้เรื่อยๆ
- - สามารถใช้งานร่วมกับฐานข้อมูลได้แทบจะทุกตัวที่มีอยู่ในตลาด
- - สามารถใช้สร้าง framework หรือกรอบการพัฒนา
ซึ่งจะทำให้ผู้พัฒนาแต่ละคน สามารถพัฒนา application เพื่อใช้กับ
application หลักได้อย่างอิสระภายใต้กรอบ
- - เป็นภาษาที่เหมาะกับการเขียนระบบงานที่มีขนาดใหญ่
เพราะสามารถแยกย่อยออกเป็น module และนำมารวมกันภายหลัง

- XML สำหรับโครงสร้างของข้อมูล
- - เป็นโครงสร้างข้อมูลที่อ่านเข้าใจได้ง่าย และแก้ไขได้ง่าย
- - สามารถส่งผ่านระบบ Internet ออกไปได้ เพราะเป็น text mode

- UML สำหรับการออกแบบ
- - เป็นภาษาที่เหมาะกับการออกแบบโครงการขนาดใหญ่
สามารถใช้ครอบคลุมทั้งการเก็บข้อมูล การออกแบบเชิง OOP การเขียนโปรแกรม
การทดสอบ การติดตั้ง

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

[Chalermkiat]

โดยรวมเห็นด้วยกับคุณ Dreamer ทั้งหมดครับ (ถ้าจะมองกันให้ไกลนะ)
แต่ยังมองเห็นข้อดีของที่ง่ายกว่า อย่าง PHP/Framework + RDBMS(Postgres/
MySQLX อยู่ครับ

[Zhuq!]

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

ความต้องการทั้งหมดที่หลายคนได้ยินได้ฟังมาเกี่ยวกับระบบบัญชีนั้น
เนื้อแท้แล้วไม่ใช่สิ่งที่เป็นงานด้านบัญชี แต่โดยมากจะเป็น requirement
ของฝ่ายบริหาร หรือไม่ก็ฝ่ายการตลาดที่มักจะมี requirement แปลกๆ
จนยากแก่การให้บริการจนหนำใจ โดยเฉพาะในเร่องของการแสดง report
ที่แทบจะหาจุดพอดีของทุกองค์กรไม่ได้

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

การติดต่อกับระบบฐานข้อมูล แม้ว่าเราจะเล็งไปที่กลุ่มของ open source
ด้วยกัน แต่เราต้องไม่ลืมว่า องค์กรหลายแห่งเสียเงินเสียทองซื้อ DBMS
ราคาแพงๆ มาแล้ว และเป็นเรื่องยากหากเราจะแนะนำให้เขาเอาไปโยนทิ้ง ...
เพราะฉะนั้น สิ่งที่จะเกี่ยวข้องกับ DB
จะต้องตรงไปตรงมาถึงระดับฐานรากของ DBMS ที่ทุกค่ายมีอยู่ร่วมกัน
มันจึงจะสามารถรองรับได้กับทุกระบบ

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

On Dec 14, 2:16 pm, Chalermkiat <chalermkiat.kaewsa...@gmail.com>
wrote:

[Dreamer]

ขอปรัชญาลูกทุ่งสักนิด งุงิ ไม่ว่ากัน

ความเรียบง่าย มักจะมีความซับซ้อนแฝงอยู่ภายในเสมอ

อิอิ คิดมาสดๆ เลยนะเนี่ย

[Dreamer]

เพราะเรื่อง db ถ้าผูกติดกับอะไรสักอย่าง หลายๆบริษัทที่ซื้อ DB แพงๆ
มาคงจะใช้งานไม่ได้ ผมเลยไม่ได้เสนอ db แต่เสนอ XML เป็นโครงสร้างแทน
เพื่อที่จะสามารถนำไปใช้ร่วมกับ db ต่างๆ ได้ตามความเหมาะสม ซึ่งจริงๆ
แล้วมันมีมาตรฐานของเทคโนโลยีนึงชื่อ JCR หรือ Content Repository
ซึ่งจะสามารถทำให้เราบันทึกข้อมูลลงในฐานข้อมูลได้อย่างง่ายดาย
แถมปรับเปลี่ยนโครงสร้างของข้อมูลได้อย่างอิสระด้วย ซึ่งมี API ของ java
ที่ implement เทคโนโลยีนี้อยู่ตัวหนึ่งชื่อ Apache Jackrabbit
แต่อย่างไรก็ตามอะไรที่แสนง่ายดายก็มักต้องจ่ายด้วยราคาที่แพงขึ้นเสมอ
(แพงขึ้นนิดนึงมั้ง)

On Dec 14, 2:37 pm, "Zhuq!" <viruzh...@gmail.com> wrote:

[upatan abc]

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

เมื่อ ธันวาคม 14, 2009 3:24 หลังเที่ยง, Dreamer <asuwa...@gmail.com> เขียนว่า:

--

You received this message because you are subscribed to the Google Groups "AcKernel" group.
To post to this group, send email to acke...@googlegroups.com.
To unsubscribe from this group, send email to ackernel+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ackernel?hl=en.

[Manatsawin]

ผมเสนอโมเดลนี้ครับ:

Frontend:

- PHP Application

- ติดต่อผ่าน  backend ผ่าน REST หรือ SOAP API (แล้วแต่เวลาที่มีพอพัฒนา)

- Framework อาจจะไม่ต้องใช้ แต่เราจะต้อง wrap REST API ให้เรียบร้อย หรือหา framework SOAP ที่ใช้ได้ดีครับ

Backend:

- Python Application

- เข้าถึง DB ผ่าน ORM อย่าง SQLObject, SQLAlchemy, Storm

- มี REST หรือ SOAP API ให้

ลักษณะลองนึกถึง Twitter API น่ะครับ

ที่ต้องแยกสองส่วนออกจากกันนี้ นอกจากในเรื่องของภาษา (จะชี้แจงต่อไป) แล้วยังมีเรื่องการ scalable อีกครับ กล่าวคือหากบริษัทที่ใช้งานต้องการทำระบบหลายๆ ส่วน ก็จะสามารถติดตั้ง backend ไว้ในเครื่องเฉพาะ (ซึ่งในเครื่องดังกล่าวอาจจะมี DBMS เลย) frontend ไว้ในอีกเครื่อง และอาจจะแยก application ส่วนตัวไว้เป็นเครื่องๆ ไป ทำให้เกิดความปลอดภัยคือ backend ไม่สามารถเข้าถึงผ่าน internet ได้ครับ และการเขียน application ส่วนตัวก็เป็นเรื่องง่ายขึ้น เพราะแทนที่จะต้องไปนั่งงม DB ของเราและเกิดความเสี่ยงต่อการทำให้ frontend ของเราเสียหาย ก็เปลี่ยนไปติดต่อผ่าน API แทนซึ่งจะทำให้ติดต่อง่ายดายขึ้นโดยไม่อิงกับภาษาใดๆ ครับ

นอกจากนี้ที่แนะนำให้ใช้ Python เนื่องจากมีเฟรมเวิร์คสามตัวที่กล่าวมาข้างต้น (เหมือนกัน แค่ syntax ต่างกันครับ) ซึ่งจะทำให้การออกแบบ DB ง่ายขึ้นโดยเขียนเป็นภาษาไพธอนเอง (เขียนคลาส) จากนั้นโปรแกรมจะจัดการฐานข้อมูลเองครับ โดยทั้งสองตัวรองรับระบบหลายชนิด เช่น SQLite MySQL PostgreSQL FireBird MS SQL เป็นต้น ทำให้ไม่ต้องมาตัดสินใจเอง (ทั้งนี้อย่าลืมนะครับว่า DB แต่ละตัวมีความสามารถไม่เท่ากัน เช่น SQLite มีน้อยสุด ซึ่งผมเองคิดว่าเราคงจะไม่ต้อง support ตรงนี้ถ้าจำเป็นจริงๆ หรือ degrade ตัวเอง (ตัดฟีเจอร์ที่ใช้ออก) และควรจะรองรับ PostgreSQL เป็นขั้นต่ำครับ เพราะมีฟีเจอร์พอสมควรไม่น่าจะมีเหตุผลที่ไม่รองรับ ตัวอย่างโปรแกรมที่ใช้ Storm ORM + PostgreSQL เช่น Launchpad ครับ (Storm เองรองรับหลายระบบ แต่ Launchpad ใช้ SQL เขียนมือบางส่วนจึงบังคับ Postgre ครับ))

สำหรับ Model การส่งข้อมูลผมคิดว่าถ้าเป็น SOAP มันน่าจะเป็น XML อยู่แล้วนะครับ แต่ถ้าเป็น REST แนะนำว่าน่าจะทำให้โปรแกรมเขียนดึงข้อมูลออกมาได้ แล้ว wrap คำตอบตาม request เป็น XML, YAML, JSON ครับ (แต่ในส่วนโปรแกรมของเราคิดว่าควรใช้ JSON เนื่องจากมีขนาดเล็กที่สุด overhead ต่ำ)

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

2009/12/14 Dreamer <asuwa...@gmail.com>

[Zhuq!]

เคยได้ยินอิทธิฤทธิ์ของ XML มาเหมือนกันครับว่า
มันสามารถสอดแทรกไปได้กว้างมากๆ เพราะความเรียบๆ ของตัวมันเอง ...
ว่าแต่ว่าคนอื่นๆ ว่าไงบ้างล่ะครับ?

ส่วนที่คุณ Dreamer
บอกว่าความเรียบง่ายมักจะแฝงความซับซ้อนอยู่นั่นก็จริงครับ :D
เพราะกว่าจะทำให้ทุกอย่างมันดูเข้าใจง่ายๆ นี่ คิดกันสาหัสเลยครับ :P
โดยเฉพาะโปรแกรมประเภทนี้ที่ต้องสื่อสารกับ users ให้เข้าใจได้ง่าย
รับรองว่าไม่หมูแน่นอน :)

> ...
>
> read more >>

[Zhuq!]

:D น้อง will เอ่ยเรื่อง REST กับ Python นี่ชอบใจมากเลย ผมชอบ concept
แบบนั้น แต่เขียนเองไม่เป็นเลยไม่บังอาจเอ่ยถึงครับ :D จะมีใครเอ่ยถึง go
language มั่งมั้ยเนี่ย? :P

> 2009/12/14 Dreamer <asuwanna...@gmail.com>

> ...
>
> read more >>

[Dreamer]

Manasawin นี่คือ willwill เหรอครับ ดีจังครับ เก่งจัง
ผมแอบเป็นแฟนความรู้ willwill มาตั้งแต่แรกแล้ว น่าทึ่งมาก

ขอเรียกน้อง will ตามคุณ Zhuq! นะครับ
สำหรับ model ที่น้องwill นำเสนอก็คือ เราทำ web server
ไว้แล้วไปเรียกใช้ web service ซึ่งอาจจะอยู่กับฐานข้อมูล หรือแยกกันอยู่
มาใช้งาน ถูกต้องไหมครับ ซึ่ง web server ก็จะทำหน้าที่เป็น UI
ให้กับระบบต่อไป ซึ่งถ้าจะว่าไปแล้วก็เป็นข้อเสนอที่ดี
แต่อยากให้คิดถึงอีกนิดหนึ่งตรง Security ระหว่าง web server กับ web
service ว่าจะมีวิธีแก้ไขตรงนี้หรือไม่ พอจะเอา SSL มาใช้ร่วมด้วยก็จะดี

ข้อเสียของภาษา Java ที่ผมเองก็หนักใจอยู่มากก็คือ
มันเรียนรู้ได้ค่อนข้างยาก
และกว่าจะหาคนที่จะเก่งพอที่จะเขียนได้มาก็ต้องใช้เวลาในการพัฒนาคนพอสมควร
ซึ่งตรงกันข้ามกับ Python ที่น่าจะพัฒนาคนเข้ามาใช้งานได้ง่ายกว่า

แต่ภาษา Python เองก็มีข้อน่ากังวลอยู่จุดหนึ่งในเรื่องของความเร็ว เพราะ
python เป็น interpreter จะทำงานได้ช้ากว่า java มากพอสมควร
การที่จะนำมาใช้เขียน project ใหญ่ๆ
ที่มีความซับซ้อนสูงจะทำให้ระบบช้าลงหรือไม่อย่างไรครับ แต่ถ้า project
มีการใช้งานไม่บ่อยมากนัก python ก็น่าจะเป็นทางเลือกที่ดีกว่าเยอะ
แต่ก็ได้ยินมาว่า Python สามารถนำไปแปลงเป็น bytecode แบบ java
ซึ่งจะทำให้ความเร็วเพิ่มขึ้นมากกว่า 40% --> JPython อีกทั้ง java และ
Python สามารถเรียกใช้งานกันได้ผ่าน JPE ซึ่งนับเป็นเรื่องที่น่าดีใจ
เพราะเราอาจจะทำ java เป็น system language ให้ Python
เรียกใช้ซึ่งก็น่าจะเพิ่มความเร็วของ project ได้ดียิ่งขึ้น

โดยใจจริงแล้วผมอยากจะเลือกใช้ soap เป็นโปรโตคอลระหว่าง front กับ back
เพราะว่ามัน support ebXML
ซึ่งเป็นโปรโตคอลสำหรับใช้ในงานในธุรกิจโตยเฉพาะ
แต่อย่างไรก็ตามเราก็อาจจะใช้ทั้ง SOAP และ REST
ร่วมกันทำงานตามความเหมาะสม

> ...
>
> read more >>

[Dreamer]

หงะ ซ้ำ

> ...
>
> read more >>

[upatan abc]

เว็บเซอร์วิสมันเป็นลักษณะนี้ครับ โปรแกรม stardict เรียกใช้ฐานข้อมูลของ longdo จริง ๆ คือไม่จำเป็นต้องเป็นฐานข้อมูลนะครับ อะไรก็ได้แล้วแต่เซอร์วิสที่จะเปิด ส่วน ui จะเป็นอะไรก็ได้เช่นกัน อาจจะเป็นเว็บก็ได้ หรือเป็น native apps ก็ได้ ตัวอย่างที่เห็นชัดเจนก็เช่น twitter ไงครับ โพสต์ผ่านหน้าเว็บของ twitter ก็ได้ หรือเรียกใช้ผ่าน client ต่าง ๆ ก็ได้

เมื่อ ธันวาคม 14, 2009 9:54 หลังเที่ยง, Dreamer <asuwa...@gmail.com> เขียนว่า:

> ...
>
> read more >>

[mangmo]

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

On Dec 15, 8:40 am, upatan abc <upa...@gmail.com> wrote:
> เว็บเซอร์วิสมันเป็นลักษณะนี้ครับ โปรแกรม stardict เรียกใช้ฐานข้อมูลของ
> longdo จริง ๆ คือไม่จำเป็นต้องเป็นฐานข้อมูลนะครับ
> อะไรก็ได้แล้วแต่เซอร์วิสที่จะเปิด ส่วน ui จะเป็นอะไรก็ได้เช่นกัน
> อาจจะเป็นเว็บก็ได้ หรือเป็น native apps ก็ได้ ตัวอย่างที่เห็นชัดเจนก็เช่น
> twitter ไงครับ โพสต์ผ่านหน้าเว็บของ twitter ก็ได้ หรือเรียกใช้ผ่าน client
> ต่าง ๆ ก็ได้
>

> เมื่อ ธันวาคม 14, 2009 9:54 หลังเที่ยง, Dreamer <asuwanna...@gmail.com>เขียนว่า:

> ...
>
> read more >>

[Chalermkiat Kaewsanay]

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

2009/12/15 mangmo <maha...@gmail.com>:

[อวยชัย]

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

[Dreamer]

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