Ruby - Ruby on Rails

ขุดมาถามอีกที 

ณ วันนี้ก็ยังไม่ได้ลองหรอกนะ แต่สงสัยว่า เวลาการใช้งานจริงๆ
จะเหมือนกับ php มั้ย

อย่าง php เป็นไฟล์ที่มี extension .php
เวลาใช้งานก็เรียกใช้ได้ตามชื่อเลย
เวลาเก็บไฟล์ ไว้ใน root ของ html document
ก็เรียกมันได้เลย

php framework อย่าง PEAR ก็ใช้ include path จาก config ได้



แล้ว RoR ล่ะ เป็นแบบไหน 

จากที่ดูจากหลายๆ เว็บที่บอกว่าเป็น RoR มันใช้ url แบบ part
เช่น ror.com/page/content/


ก็เลยงงๆ ว่ามันยังไง แล้วจะเอามาใช้กับ virtual host ได้มั้ย

คือกำลังคิดจะทำโฮสที่ใช้ RoR นี่ได้แหละ

แต่ปัญหาคือผมไม่รู้จัก RoR แบบเข้าใจ 

อย่าง php เป็นไฟล์ที่มี extension .php


จากที่ดูจากหลายๆ เว็บที่บอกว่าเป็น RoR มันใช้ url แบบ part
เช่น ror.com/page/content/


ก็เลยงงๆ ว่ามันยังไง แล้วจะเอามาใช้กับ virtual host ได้มั้ย

ตอบรวมๆแล้วกันนะครับ
หลักการของ script engine ของ web server จะประกอบด้วย 3 ส่วน
1. web server (virtual host ทำที่ web server)
2. ส่วนเชื่อมต่อ script engine กับ web server ซึ่งอาจเป็น CGI,FastCGI หรือ เป็น Server Extension เช่น ISAPI..
3. ตัว engine เช่น php.exe asp.dll ..etc

ถ้าส่วนที่สามเขียนเป็น extension ของ web ก็จะไม่มีส่วนที่ 2 (2 กับ 3 รวมกัน)

สำหรับคำถามผมตอบดังนี้ครับ
1. ruby มี นามสกลุล .rb เหมือนกับ PHP (ที่มีนามสกุล php)
2. การ include ก็เหมือนกัน (ขึ้นอยู่กับ syntax ของภาษา)
3. การอ้างตำแหน่งเว็บที่ไม่มีนามสกุล ใน PHP ก็ทำได้เช่นกัน (ขึ้นอยู่กับ config  ในเว็บ server เช่นให้หา .htm ก่อน .html และ ก่อน .php .. ถ้าไม่มี index.htm(l) หรือ default.htm(l)
สรุป Ruby นิยมใช้แบบ auto (ไม่แสดงนามสกุล)ก็แค่นั้น
4.เรื่อง Ruby บน Virtual Host ทำได้แน่นอน(Virtual Host ทำบน web เรื่องไม่เกี่ยวข้องกับ Ruby ถ้า *Nix ขอให้ run CGI/FastCGI ก็สบายๆครับ)

-----------
ใช้เวลาตอบนานเพราะกำลังดูศาลตัดสิน 

ขอบคุณครับ 


แต่เหมือนจะยังไม่ใช่ที่ผมอยากรู้แฮะ 

เหมือนผมถามไม่ถูก งงตัวเองแฮะ สงสัยต้องลองของจริงก่อนซะแล้ว

พี่เอ้ไปดูบล็อกผมดิ / ของห้าโอก็ได้
ไม่รู้เกี่ยวกันไหมนะ แต่มันแสดง url เป็น path เหมือนกัน

(จะมีประโยชน์ไหมเนี่ย)

ไำม่ใช้อย่างนั้น นั่นมัน rewrite 

เอาเป็นว่าหยุดไว้ก่อนดีกว่า รู้สึกว่าสื่อไม่ถูก 

ถ้าหมายถึง ruby web hosting (เพราะคำว่า virtual host มันคลุมเคลือ) ก็ทำได้แน่นอนเช่นกัน(ลอง search คำว่า  ruby web hosting จะมีตูม)

เรื่องติดตั้งบน webhost ก็ดูๆ อยู่เหมือนกัน แต่ไม่ได้ดู control panel ตัวอื่นนอกจาก ensim

http://forums.theplanet.com/index.php?showtopic=64927

คราวที่แล้วเดฟลงให้ ไม่ได้ทำเอง

http://www.softwaredeveloper.com/features/best-ruby-on-rails-061307/
Rails in Action: The 56 Best RoR Driven Sites

ขุดๆๆ




นาน ๆ ไอ้กวางจะโพสอะไรมีสาระซักที





ใครยังอยากเขียน Ruby on Rails อยู่บ้างเอ่ย

ตอนนี้ดุกเพิ่งได้ tutorial ของ Michael Hartl เรียนเรื่อง Ruby on Rails ค่ะ

เจ้านายให้มาเป็นคลิปวิดีโอ (มีคลิปสอน Ruby on Rails จาก Lynda.com แนบมาให้ด้วย)

แต่จริง ๆ หนังสือก็มีค่ะตาม link เลย

http://ruby.railstutorial.org/ruby-on-rails-tutorial-book

ประมาณว่า ใน link นั่นมันสอนเขียน twitter ว่างั้น

ขอไปลองก่อนนะคะ ในเล่มมันใช้ textmate

ของดุกตอนนี้ใช้ framework ของ RubyMine 3.1.1 ค่ะ



ปล. rails เวอร์ชั่น 3.1.x ขึ้นไปมันสั่งให้ install gem coffee script ด้วยอะ ถ้าไม่ได้ใช้แนะนำให้ลงเวอร์ชั่น 3.0.x นะคะ

(coffee script เป็นการเขียนโปรแกรมด้วยภาษา javascript
แต่เขียนสั้นลง มีประโยชน์ตรงที่มันตัด syntax ภาษา javascript ที่มันจะเยิ่นเย้อ วงเล็บเยอะมาก ใช้คำซ้ำซ้อน ให้เขียนง่ายยิ่งขึ้น)

 +

  ขุด

Setup Ruby http://37signals.com/svn/posts/2998-setting-up-a-new-machine-for-ruby-development

It used to be a jarring experience to setup a new machine for development, but progress has paved the dirt road into a silky smooth autobahn. These are the tools we use today:

    Homebrew: Remember how painful it used to be to get imagemagick installed? Now it takes about a minute. “brew install imagemagick”. Same story for git and other Linux dependencies.
    rbenv/ruby-build: We have some apps running on Ruby 1.8.7, some on 1.9.2, and some on 1.9.3. ruby-build makes it easy to compile all three, rbenv makes it easy to switch between them on a per-project basis. We run rbenv in production as well, so all you need to do to change the Ruby version there is alter .rbenv-version—development and production is always on the same page.
    Bundler: Not everyone at 37signals loved Bundler at first, but now that it’s stable, they’ve been won over. I now curse whenever I have to use an old application that hasn’t been setup with Bundler. Manually tracing down dependencies?! How prehistoric!
    rake setup: All our apps has a rake setup task that’ll run bundler, create the databases, import seeds, and install any auxiliary software (little these days) or do any other setup. So when you git clone a new app, you know that “rake setup” will take care of you.
    Pow: No more messing with Apache or nginx for local development. All it takes for Pow to add another app is a symlink. All the apps are always configured and available at basecamp.dev, highrise.dev, etc without messing with the hosts file either.

Thanks to Max Howell for Homebrew, Sam Stephenson for rbenv/ruby-build and Pow, and Carl Lerche/Yehuda Katz for Bundler. Thanks to them, starting from scratch has never been easier.

แล้วก็ข่าวของอาจารย์ที่มอ เอาเว็บ Gotoknow ขึ้น Cloud ของ Amazon
http://www.gotoknow.org/blog/averageline/451861

ส่วนบริการเว็บและส่วนบริการการประมวลผลนั้น เนื่องจากซอฟต์แวร์ของ GotoKnow พัฒนาโดยใช้เทคโนโลยี Ruby on Rails ซึ่งมีผู้ให้บริการ "ทับทิมใส่รางบนก้อนเมฆ" (Cloud Computing for Ruby on Rails Applications) รายใหญ่ๆ อยู่สองรายคือ Heroku กับ EngineYard ซึ่งผมตัดสินใจเลือกใช้บริการจาก Heroku ซึ่งมีบริการที่ครบวงจรและสะดวกกว่า ซึ่งเป็นการตัดสินใจที่ไม่ผิดเพราะปัจจุบัน Heroku เติบโตและมีบริการใหม่ๆ เพิ่มเติมอีกมาก อีกทั้งยังสะดวกในการใช้งานมากขึ้นเรื่อยๆ

การย้ายมายัง Heroku นั้นง่ายดายเหมือนปอกกล้วยเข้าปาก จนไม่มีอะไรเป็นประเด็นให้เล่า ของเขาดีจริงๆ ขอบอก และหลังจากย้ายมา Heroku แล้วก็เหมือนยกภูเขาออกจากอกผม (แล้วเอาก้อนเมฆมาใส่แทน) ในตอนนี้ไม่ว่า GotoKnow จะมีการใช้งานมากแค่ไหนผมก็ไม่หวั่น ผมเพิ่มและลด "dyno" (หรือหน่วยให้บริการการประมวลผลเปรียบเสมือนเครื่องแม่ขายหนึ่งเครื่อง) ได้เพียงเสี้ยววินาที

นอกนั้นบริการเสริมอื่นๆ ของ Heroku (และบริษัทพาร์ทเนอร์ของเขา) ก็สะดวกมาก อาทิเช่นระบบการส่งอีเมล ซึ่งก่อนหน้านี้ต้องดูแลเครื่องแม่ข่ายสำหรับส่งเอง ปัจจุบันใช้บริการของบริษัท SendGrid ไม่ต้องกลัวว่าใครจะมาเจาะระบบอีเมลเพื่อส่ง spams อีกแล้ว

ตอนนี้การใช้งาน GotoKnow จะมากแค่ไหนผมก็ไม่น่าห่วงอีกต่อไป ไม่มีต้องตื่นมากลางคืนเพื่อ tune up เครื่องแม่ข่ายอีกแล้ว

แต่สิ่งที่น่าหวั่นคือค่าบริการ แม้เราจะจ่ายตามการใช้งานจริงเป็นรายชั่วโมง แต่การใช้งานรายชั่วโมงของเราก็ไม่ได้น้อย อย่างเดือนที่แล้วเราต้องจ่าย Heroku ประมาณ $3,500 ดอลลาร์

เมื่อคิดเป็นเงินแล้วดูจะปริมาณมาก แต่ในความเป็นจริงแล้วไม่มาก หากคิดในทางเลือกอื่นที่เราต้องซื้อเครื่องแม่ข่ายเองและต้องจ้าง network engineer ที่มาติดตั้งดูแลระบบให้ได้เหมือนของ Heroku ต้นทุนต้องแพงกว่านี้ไม่น้อยกว่าสองสามเท่าแน่ๆ

แหม มันอ่านรู้เรื่องดีจริงๆ

อันล่างรู้เรื่องนะอ่านที่ลิงก์ซิ 

แต่ตัดมาเฉพาะส่วนที่พี่โอ้เอ้เคยสงสัยเรื่อง virtual host น่ะ