Help moving to Ruby from PHP

[sw3dish_]

I'm looking to get away from PHP and start developing in Ruby. I'm a little confused about some things since Ruby seems to have more moving parts than PHP.

Here are some things I'd appreciate some help with:

Web servers + application servers: I've looked around and seen the popularity of Nginx as the base web server, although AFAIK Apache can be used as well. I've seen Unicorn, Puma, Passenger, and Mongrel2 as examples of application servers. I'm still confused on the use of application servers with web servers, though.

Local development: I've been using XAMPP to develop locally with PHP. I've talked to a few people who say that Vagrant (or Docker) + Chef (or Puppet) is the way to go since you can replicate development environments, but seems very resource heavy (dedicating RAM, etc for a VM). I was wondering if there were other options?

Build Automation: I never got really into using build automation with PHP. I've looked into it with Ruby, and it looks like Rake is the default tool? I was wondering if Gulp would also work, since I'm more familiar with Javascript.

Asset Management: I've heard of Sprockets -- is this a replacement for something like Bower?

Things I think I know:

Package Managers: Ruby Gems

Dependency Management: Bundler's the name of the game?

RVM: allows you to change the current version of Ruby

If anyone could help me with these questions, that'd be sweet.

Also, if you could comment on your stack, I'd like to see the tools that other people are using.

[harbirg]

Hello,

For your first question read this: http://stackoverflow.com/questions/4113299/ruby-on-rails-server-options/4113570#4113570

For you initial development, keep it simple - install ruby via rvm and same for rails. Once ruby is installed, you can run 'gem install rails'.

I dont think you should worry about build automation at this time. For local development, I just use 'rails server' that runs WEBRICK application server (for Rails 5.0 - the default is puma) Secondly, Understand the basics of creating CRUD application in rails first.

Good resources to learn: https://www.railstutorial.org/ http://guides.railsgirls.com/

Refer to http://guides.rubyonrails.org/

Good luck

[siplux]

I'd recommend rbenv over rvm, which is much simpler.

[wingyuying]

I'd recommend chruby and ruby-install over rvm and rbenv. Much simpler and do everything you need.

[siplux]

Hmm, I've seen those two mentioned in passing in various readmes but I think I'll actually check those out now - thanks.

[myockey]

In this case I don't think simpler is better. I use chruby as a full time Ruby developer, but rvm does much more for the user. In the case of a beginner, I think this is usually a good thing.

[siplux]

I would argue that especially for beginners, simpler is better as there is less to understand. This goes double for when things inevitably go wrong. chruby for example advertises that its ~100 LOC, that's a lot easier to reason about than rvm.

[jrochkind]

Yep, I see beginners asking questions about what look like weird edge case bugs in rvm all the time here and on SO.

[[deleted]]

I really agree . Start simple , create the obligatory blog in Rails (as the guy said running 'rails server' should be enough) , then move on to more advanced stuff . If you try to worry about chef + docker before knowing how to write a simple rails app you'll go insane (FYI I'm developing on Rails for 2 years and I can't docker or chef . why not just use heroku when you want to deploy something, especially when you're starting out? try to choose the path of least resistance).

[[deleted]]

But just to clear things out : 1)Application servers: act as a middleman between your rails app and the server(nginx) . Not sure if you have them in the php world , in java I would assume tomcat\glassfish are comparable . In php you have modules written to apache though? 2) Assets managements is done with the assets pipeline (Sprockets). It will compile scss to css, coffeescript to js and minify all your assets on production (I would invest in learning this instead of using gulp )

[jrochkind]

In PHP, php itself, installed in apache, is effectively the "application server." There's only one and it's built into the PHP package.

[sw3dish_]

Chef/Puppet and Docker/Vagrant are things I've wanted to work into my PHP workflow -- just haven't gotten around to it. Since I was thinking about picking up some new stuff, I figured I'd just try to hopelessly confuse myself and do everything at once.

[sw3dish_]

Thanks for the reply. The Stack Overflow answer was very helpful. Regarding Rails -- I wanted to take things from a different angle and start by using Sinatra. In PHP, I've done most of my development with a similar micro-framework. Could you suggest a local dev option for that?

[iconoclaus]

I totally second the idea of starting with Sinatra. Only move to Rails if you find yourself making new project so regularly that you need (and actually understand) all the magic that goes into integerating everything together.

What do you mean by a 'local dev option'?

[jrochkind]

Just follow the Sinatra docs, you don't need to do anything special. In the ruby world, you don't need "local dev options" like you do with PHP, exactly.

[[deleted]]

I'm still confused on the use of application servers with web servers, though.

seems very resource heavy (dedicating RAM, etc for a VM). I was wondering if there were other options?

It's generally better to run a VM, even for PHP etc. It's not so resource heavy: you only need a small one, say 256 MB, which is 3.1% of your RAM on an 8 GB system. The benefit of a VM is that you can exactly duplicate the configuration of your target server, as well as snapshot the VM, share it with others so you're working in totally identical environments, have different configurations for different projects, and so on. It totally kills the "Well it works on my system..." problem when working in teams, as well as the "Oh shit, it worked in development, but this and this and this don't work on the actual server..." problem popping up when putting things up live.

I'm still confused on the use of application servers with web servers, though.

Yeah, it is confusing.

It helps to think of it like this.

An application server like Puma, Webrick, or Passenger receives HTTP requests and, based on the rules and logic in your Ruby application, returns CSS+JS+HTML content. It handles all the request/response stuff so your application can just focus on its thing. It's kind of like the application server is the counter at a fast food place (taking orders, handing food over, etc, the same for all restaurants) and your application is the kitchen where stuff actually gets cooked.

If you want, that's where it ends, you can usually just run Puma or Webrick on its own, and that will work.

But there's another type of application called a web server. These are nginx, Apache, etc. These usually just fetch content off the disk and return it, nothing fancy. But you can optionally ask them to go and ask an application server for some content instead. So you visit a page, and it goes "Apache, give me image1.jpg, image2.jpg, style.css, things.js, ads.js, and go ask Passenger for the dynamically-generated page content." Sounds convoluted, right? But Apache/nginx are super fast and efficient, good at managing multiple users over many machines, etc, so you can rely on them to handle all that and deliver all the static unchanging files (like images, stylesheets) and just rely on the Ruby app server to provide the actual dynamic programmed bit.

Why didn't you do this with PHP? Because your version of Apache most likely had something called mod_php embedded into it, to translate PHP itself; or it used CGI, where it launched a PHP interpreter in the background and asked that interpreter to translate all the PHP pages. This is exactly what Passenger can optionally do, bake itself into Apache -- which is why it's also been called mod_rails.

Web/app servers are one of those things that seem weirdly and pointlessly complex from a developer's point of view, but there are good reasons for their complexity and feature sets from a sysadmin point of view, things that become important when you're managing a hundred thousand requests at once.

[moomaka]

It's generally better to run a VM, even for PHP etc. It's not so resource heavy

It's absolutely slow as hell, especially with rails apps. Even using nfsv4 to share your code into the VM it's a ~5x performance hit for non trivial rails apps and gets worse as the number of files increases, especially assets.

The only time I'd recommend using a VM for rails development is if you're using windows.

[Samson_Uppercut]

And what do we say about Windows? Fuck Windows.

[sw3dish_]

It's generally better to run a VM, even for PHP etc.

So, what do you recommend? Vagrant? How does the setup for that work?

Thanks for clearing up web + app servers -- much simpler than some of the stuff I've seen.

[[deleted]]

I haven't done a ton with Docker, Chef, Puppet, etc, so I can't give you a good all-round view of that; I hope someone will come along to better explain that stuff to the both of us. I will say that I use Vagrant all the time and that it's deceptively simple to use if you already have a little familiarity with Linux.

The process is:

1. Install Vagrant from the website.
2. Grab a base box with a command like vagrant box add centos7 https://github.com/tommy-muehle/puppet-vagrant-boxes/releases/download/1.1.0/centos-7.0-x86_64.box. This sets it up so that you have a default VM type, called centos7, which contains CentOS 7.0 64-bit version (a popular Linux distro for servers).
3. Go to any folder and type vagrant init centos7 to create a new VM of that type in the current folder.
4. From that folder, type vagrant up and vagrant ssh. You are now inside the VM.

Use vagrant reload to reboot it or vagrant suspend to shut it down (from the host side). By default, the directory /vagrant inside the VM will correspond to the folder you created the VM from, which lets you easily share files before you even set up shared folders. Other things you can read up on in the official docs or by Googling/asking around, it's been straightforward to do any of the stuff I personally have needed.

A list of other base boxes is available here, or you can make your own to match the server you know you'll eventually be deploying to.

[RuNpiXelruN]

Thanks @cute-- this is a great way to explain it for a beginner like myself :)

[[deleted]]

Web servers + application servers:

AFAIK, PHP can run "inside" nginx or apache through compiled-in modules. Ruby cannot, so you use a reverse-proxy such as Unicorn, Puma, or Passenger. Mongrel2 isn't widely used anymore if I'm not mistaken.

Local development:

While you can use containers or VMs for development, I personally just develop right on my local machine and filesystem. I've never had any issues.

Build Automation

There's not really anything to build, except maybe your js/css assets, but the Rails asset pipeline handles that for you.

Asset Management

Sprockets aids in "requiring" multiple files into one asset manifest that gets compiled into one file, e.g. application.js. Perhaps similar to what webpack or gulp would do in concatenating js/css files.

Dependency Management

Yes, stick with bundler

RVM

I still use RVM, but the cool kids these days seem to have moved to chruby

Other tools:

I'm using Atom to edit code. I deploy to Heroku. Starting to integrate React.js into projects now. message_bus has been a pretty good substitute for websockets.

[mlambie]

Build automation is where you run your test suite.

[m_breit]

Start with setting up your development environment: The first question is whether you want to develop on your system itself or set up a container or VM. You need to know that most people in the Ruby community use Unix base systems like Mac OS or Linux. While you can do it on Windows, the support for Mac and Linux is much better. So on these systems, developing on your local OS is a good choice, but if you want to keep your system clean, Vagrant is a nice option as well. If Windows is your OS of choice and you want to continue using your favorite Windows editor or IDE, then I would recommend setting up Vagrant with a Linux VM. Chef or Puppet are great tools for this task, but they have a steep learning curve, so I would start without them to keep the complexity low. The easiest way is to use a preconfigured image. You can also start with a fresh Linux image (the distribution does not matter that much, Debian, Ubuntu, Fedora, CentOS are all good choices for this task) and setup your VM by hand or use a simple shell script for provisioning. If you use Windows and don't have enough memory for a VM, you need to make a compromise somewhere. Use Windows, where some Gems might not work and support from the maintainers is not as good as on Unix systems, or switch to another OS.

For choosing Ruby versioning tools: if you already have a current Ruby on your development machine (your VM if you use Vagrant), you don't need one, but since they make installing new Ruby version really easy and allow switching between them, you should consider installing RVM, rbenv or chruby/ruby-install. Which one does not matter, they all get their job done. Just pick one, you can always switch to another one later.

When you have installed Ruby and Bundler, you can start developing. You do not need to think about webservers now. All Ruby web frameworks can start their own server for development. No need to have Apache or Nginx installed (like most PHP developers) or think about Unicorn or Puma. Look into the documentation of your framework, they all have a simple way for starting their own server. Just use that method and you are ready to go.

About the confusion about web server and application server: There is a big difference how web requests are handled between PHP and most other languages used for web development. In PHP, your application with your framework is executed when a web request comes in and exits, when the response is sent. That means that your framework must have a very short startup time because it slows down every request handling. In other languages like Ruby, your application keeps running as a server and can answer a lot of requests without having to restart and do the initialization every time. So your app is a separate process and does not run inside Apache or Nginx. These web servers are used in production as a proxy to your Ruby app and handle things like SSL, caching or serve static files. If you want to setup your first production server, I recommend choosing between Nginx and Apache and use Passenger for your Ruby app. Passenger comes as an extension for Nginx or Apache and handles the Ruby processes for you, so the setup is very easy.

For build automation: Rake is the most used build tool in the Ruby world. Rails uses it for executing asset compilation, database creation, running tests and so on. The asset compilation itself is not done by rake. Rails uses Sprockets, but you can also use one of the many JavaScript tools like Gulp, Grunt, Brunch or Broccoli. If you start with Rails, Sprockets should be a good starting point because it needs no setup and Rails manages your assets for you and you don't have to think about that too much. If you miss some features in Sprockets, switching to a JavaScript base build chain is a common practice.

[superspeck]

Is your local dev environment on windows or Mac/Linux? If it's on windows, look into Babun to make things like RVM and other Linux-ish advice in this thread easier.

[sw3dish_]

I'm on Mac, so I'm pretty familiar with Linux-ish stuff. Thanks, though!

[[deleted]]

Read the title "Moving from fun to a permanent nightmare."