Rails for developers on Windows

[kai]

From my notes of my Windows endeavour, I've prepared a presentation
"Ruby on Rails 3 with MySQL ─ A Start Guide for newbie developers on
Windows"

which I can do at the next meeting. Do you know anybody who'ld be
interested?


Kai

[Paul Callaghan]

hi

I'll answer. Most of us use some flavour of unix for dev work, and so
windows isn't the hottest of topics.

However, it will be quite interesting to see what the current state of
windows support is like, and what it is like for people taking first
steps in ruby and rails.

What does anyone else think?

Paul

> --
> ================
>  -- ncl.rb --
> ================
> To post to this group, send email to ncl...@googlegroups.com
> To unsubscribe from this group, send email to ncl-rb-un...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/ncl-rb?hl=en-GB

[Philip Poots]

Same. Prefer Unix, but I would be interested to see what Windows support is like now. I remember when I started doing Rails they had InstantRails, which was passable, but I soon went out and splurged my student loan on a macbook, specifically because support was better for Rails, and I was scared of Linux back then. 

[Paul Callaghan]

I once tried to get instant rails installed on a certain university's
pc network. I was scared of trying to get a class of MSc students to
use linux.

The installation didn't work so they suggested installing instant
rails on a USB stick. Ouch!

[Jase]

To add my 2 cents as well, I spent about a year of using Rails under
Windows in my first year up here probably about 5 years ago.

One of the huge annoyances for me was the fact Windows has exceptionally
shoddy threading performance... As I made the transition from Windows to
Linux I had Linux setup in a VM under Windows and had it running full
screen on my second monitor. The setup worked very nicely and I found
that despite the overhead you associate with VM's (particularly as there
was no hardware virtualisation acceleration back then or IOMMU's) Ruby
was probably 50% faster running in a Linux VM than it was natively in
Windows. Likewise I found with cygwin, any sort of compiling process
would be painfully slow due to the fact process spawning on Windows so
bad.

I also recall a lot of gem being painful to use where they required
binding to some library (e.g. mysql, RMagick). I wonder if this has
improved with time.

Ultimately, a lot of newcomers do initially use Windows, and I think
there is some significance in either making Rails more Windows friendly
to help adoption, or some sort of process to soften the migration from
Windows to *nix (i.e. either buy a Mac if you can throw money at the
problem, or do something like the VM trick I used)

J.

[David Legg]

Interesting topic really since most people will have started off using
Rails in some fashion on Windows. I do actually know of, or did know of,
one or two production Rails systems that run on Windows! As others have
indicated the standard response is generally for people to develop and
run on Linux, or at least Mac OS X, systems. However, there will some
people who might well be sitting in rather restrictive environments.

The difficulties with running on Windows can be pretty large, especially
where gems requiring compilation are concerned and Ruby is
excruciatingly slow on Windows as well. Basically, it ends up being
virtually impossible unless you can tack on a Linux environment in some
way with Cygwin or as a VM running on Windows. I did play with getting a
Cygwin environment running once for development but had some real
difficulties bridging the Cygwin and native Windows userspaces. Software
availability was also a problem in Cygwin.

Personally, I would lean towards running a Linux VM and deploying to it
as you would any other environment. It's probably a useful thing to be
doing anyway since most people will be deploying to Linux in production
and such an approach would get your development environment as close as
possible to production. Something I'm most in favour of since I've seen
annoying and time consuming bugs in production systems that developers
swear they don't see on their development machines.

David

[Stephen Lloyd-Hirst]

I developed on Windows with an ide using Jruby performance was ok but the incompatibility with gems, problems compiling on Windows led us to use Linux vm. Until you guessed it now don't even have Windows on our machines and use Ubuntu 11.10 64-bit.

At the magrails conference the question was asked put your hand up if you develop on Windows. Nobody did followed by a room full of laughter. The majority of people I met at the conference used Mac's.

--
================
 -- ncl.rb -- ================
To post to this group, send email to ncl...@googlegroups.com

To unsubscribe from this group, send email to ncl-rb-unsubscribe@googlegroups.com

[Jonty]

I must also add my experience.

Luis Lavena's installer and mingw environment makes ruby on windows
almost pleasurable. I spent maybe 2 years doing my learning of ruby
under windows and it works well. All right not every gem installed but
as I mention Luis' efforts have made a big difference and now you can
run most things comfortably on windows. Obviously now I am happy under
Linux and Windows is, as of last weekend, no longer in our house.

But if you have to use Windows, ruby will work well if you follow the
advice.

[James Dean Shepherd]

Like others, I too would find it interesting to see how well Rails development on Windows works nowadays.  It was only 9-10 months ago I was developing a (albeit extremely simple) Rails app in Windows, and I have to say it worked fine for me.  As of a few months ago, however, Linux is now my development OS, and there will be no going back.

[Philip Poots]

Ryan Bates recently did one of his Railscasts [1] on the Vagrant gem,
which uses Oracle's virtual box for exactly the setup you describe
David. It's well worth a look, because Virtual Box runs across the
three major platforms and allows you to use your Windows machine to
run a Rails dev environment on Ubuntu (or other flavour of Linux). I
considered it briefly even on my shiny new Mac because setting up
PostgreSQL can be a real pain (and I like to run with the same
production db in development) but in the end decided to compile
everything from source and leverage launchd for running the various
services.

But the Vagrant/VirtualBox route allows you to start playing with
Puppet or Chef to get your development environment setup that you can
then use for rolling out to production.

Does anyone have any experience of going down the VM route? One of the
things I was afraid of was degraded performance on the dev machine
because you're running a virtual machine. I guess you could always
just do what this guy does and develop from your iPad [2].

Philip

[1] http://railscasts.com/episodes/292-virtual-machines-with-vagrant
[2] http://yieldthought.com/post/12239282034/swapped-my-macbook-for-an-ipad

[kai]

I now have a windows development system I can use for effective in-
house Rails & db managment projects. After weeks of figuring out
niggly and sloppy compatibility issues, I've actually started to do
some useful Rails programming.

Rather than Windows itself, there are much significant annoyances due
to differences between Rails 2 + Rails 3, rails + rake, .rb + .erb,
the hit+miss arcane syntax differences in command-line helps (& their
dreadfully slow response, in windows), versions of individual gems
that are suspect, the fudge for the mysql2 gem, installation packages
that you wish had done a bit more work for you, 5 different but
eqaullay valid ways of start/stopping daemon services,... Then
there's a bewidering array of new concepts in Ruby, symbol objects,
hash, scaffold, yml, routes, git, deprecation, dependencies, migrate,
MVC, Action, Active, not encountered elsewhere.

Honestly I never thought it was going to be such a hassle. But I am
happy that I can use Rails for development work. On-balance, I have to
be more grateful than grumbly as the cool technology is open source.


Kai

[David Legg]

I've heard of the Vagrant gem but haven't really used it because I moved
away from using heavy-duty virtual machine platforms like VirtualBox and
VMware a little while ago.

Even on the Mac these days I'm really shying away from using Macports or
even Homebrew because you can always end up with a bit of a serious mess
once you get multiple projects using multiple gems, multiple versions of
Ruby with Postgres/MySQL using multiple databases and when you start
experimenting. I don't like hand configure make compiling because that's
what we have package management systems for.

For quite a while I've been using KVM on Linux if I need a full-blown
virtual machine and OpenVZ for staging environments, which are
lightweight Linux virtual containers that share the same kernel as the
host machine but with a separate userspace. These are as close to native
speeds with virtual environments as you'll get. You can then use
Chef/Puppet to configure what you need quickly when you need to do some
swift testing without affecting your desktop. Setting it up is a time
consuming task though.

The iPad thing was very interesting, and he uses Qt too! The trade-off
is that you have at least a partly remote development environment so you
always need network access. For remote X desktops I'd be looking at NX
rather than VNC though.

In terms of Linux staging/test/development (not desktop) distribution my
seriously opinionated opinion is use Gentoo, or at the very least an
environment that makes it amenable to compiling software. No matter what
you do you'll encounter gems that need something compiled, you'll need
the source code and the toolchain installed, or worse, you might need an
updated version of something that isn't in a binary repository. On top
of that you might well end up hand compiling a version of Ruby at some
point, and with Phusion's stuff this will bring in Nginx and Passenger.
Oh, and make sure you use gems within the Ruby gem system and not from
the package repository of your distribution, no matter what Debian might
think.

David