A Ruby appliance: What would you include?

[Aldric Giacomoni]

Yeah, we should move this whole shebang off-list ASAP.

Here's a wave for the non-Ruby, non-programming tools we ought to have
set up on the distro:
https://wave.google.com/wave/#restored:wave:googlewave.com!w%2BWsu54CnMC.1

 

[Marnen Laibow-Koser]

VMWare allows "teams" of virtual machines, which can be set up in their
own little network. It's something to think about, especially now that
VMWare Player is available for free and all.

I don't know if Ubuntu is a good choice though. It's a can of worms, so
I don't really want to open it, but I suggest Gentoo: it has a tool
available to switch painlessly between Ruby 1.8 and 1.9, which allows
for any and all setup on editors and such to be simple and just link to
#!/usr/bin/ruby ... For instance.

It wouldn't be hard to do this in Ubuntu either, I think, and Ubuntu
configuration is generally very easy.

You'll definitely need to include emacs and vim, along with the
appropriate plugins, and probably Netbeans/Aptana, so people can check
out different ways of developing.

No, I don't think it's appropriate to include an IDE in something like
this. Perhaps there should be links to info about some, but I see no
reason that they should be preinstalled.

Sticking a bunch of tutorials on a folder on the desktop would be a good
idea as well.
Yup.




As a tool, this could come in very handy.

Best,

 

[Marnen Laibow-Koser]

Yeah, we should move this whole shebang off-list ASAP.

Why? It's on topic and would benefit from staying here.

I underestimated the amount of attention this would generate, I have to
say.


It's taking its sweet, sweet time.

Well, it should be back on after I had my allotted sleep cycle.

Best,

 

[Phillip Gawlowski]

Why? It's on topic and would benefit from staying here.

Organization. Email is a difficult medium to keep track of a project.

And while an ML is excellent to kick start a project (just like we are
doing here), it ain't a good repository for code, or to discuss minutiae.

 

[Phillip Gawlowski]

It wouldn't be hard to do this in Ubuntu either, I think, and Ubuntu
configuration is generally very easy.

Solvable in a script, that deletes the current symlink, and creates a
new one. Call it switch, give it the commandline argument "ruby", and
you have a nice little "switch ruby" command.

No, I don't think it's appropriate to include an IDE in something like
this. Perhaps there should be links to info about some, but I see no
reason that they should be preinstalled.

Couple of reason pro-IDE:
- Most developers are already used to IDEs, be it Visual Studio,
NetBeans, or IntelliJ IDEA.
- IDEs (especially NetBeans, IME), provide excellent support for syntax
highlighting, debugging, and plugin management (NetBeans has a nice
integration for RubyGems, for example).

Cons:
- Redistribution isn't always possible
- Redistribution can create a significant overhead
- It's one more thing to keep track of.

A simple text editor that allows to run Ruby scripts in its buffer(s) at
the push of a button is already a great step forward, IMO.

 

[Marnen Laibow-Koser]

Solvable in a script, that deletes the current symlink, and creates a
new one. Call it switch, give it the commandline argument "ruby", and
you have a nice little "switch ruby" command.
Right.


Couple of reason pro-IDE:
- Most developers are already used to IDEs, be it Visual Studio,
NetBeans, or IntelliJ IDEA.

That's actually a reason not to include an IDE. Developers used to Java
or C* tend to think that all development requires an IDE. It's probably
a good idea to expose them to the fact that an IDE is less necessary for
Ruby.

In other words, we don't want people rushing to Eclipse simply because
they've always used it. Let 'em install it if they want to, but
hopefully they'll fire up Emacs or Kate first.

- IDEs (especially NetBeans, IME), provide excellent support for syntax
highlighting, debugging, and plugin management (NetBeans has a nice
integration for RubyGems, for example).

Cons:
- Redistribution isn't always possible

All free IDEs are redistributable, aren't they?

- Redistribution can create a significant overhead
- It's one more thing to keep track of.

If we do include IDEs, then I would also push for the inclusion of
full-featured editors like jEdit and KomodoEdit. I actually think these
are far more useful for most Ruby work than are IDEs.

A simple text editor that allows to run Ruby scripts in its buffer(s) at
the push of a button is already a great step forward, IMO.

Perhaps.

Best,

 

[Steve Klabnik]

[Note: parts of this message were removed to make it a legal post.]

Solvable in a script, that deletes the current symlink, and creates a new

A script... called rvm perhaps?

 

[Phillip Gawlowski]

That's actually a reason not to include an IDE. Developers used to Java
or C* tend to think that all development requires an IDE. It's probably
a good idea to expose them to the fact that an IDE is less necessary for
Ruby.

In other words, we don't want people rushing to Eclipse simply because
they've always used it. Let 'em install it if they want to, but
hopefully they'll fire up Emacs or Kate first.

That's myopic. If you want to win over people to use Ruby, you need to
make the transition as easy as possible.

Jeff Attwood wrote an actually worthwhile article on that:
http://www.codinghorror.com/blog/archives/000290.html

There's also the concept of "conversion" in marketing: The easier you
make it for people to go and get/do something, the more people get / do
that something.

All free IDEs are redistributable, aren't they?

No. Not all Open Source licenses are compatible to each other, nor does
"free" automatically mean "open source", either.

If there were a redistributable Visual Studio Ruby IDE, I'd include that
in a heartbeat, damn the torpedoes, just to grab the legions of Windows
developers.

If we do include IDEs, then I would also push for the inclusion of
full-featured editors like jEdit and KomodoEdit. I actually think these
are far more useful for most Ruby work than are IDEs.

If a case can be made, then sure. But we don't have endless room,
either, alas, so there will be cuts. Which is why IDEs are lower on the
priority list than a good editor that runs Ruby code on the push of a
button.

 

[Phillip Gawlowski]

A script... called rvm perhaps?

Extremely simplified in the "Ruby Beginners" VM, yeah.

If there'll be more than one Ruby variant, anyway (I'd go straight for
1.9.1, actually).

 

[Steve Klabnik]

[Note: parts of this message were removed to make it a legal post.]

Is "rvm install 1.8 && rvm use 1.8" too complicated? That's all I use it
for, anyway.

I'd agree, put 1.9.1 on by default.

 

[Phillip Gawlowski]

Is "rvm install 1.8&& rvm use 1.8" too complicated? That's all I use it
for, anyway.

For a beginner, potentially new to Linux? Yup.

And "switch ruby" sounds more natural, too.

 

[Aldric Giacomoni]

That's myopic. If you want to win over people to use Ruby, you need to
make the transition as easy as possible.

Precisely why we should have at least one IDE. Maybe we can talk to the
Jetbrains people and have a limited version of Rubymine on there; but
that may be a little later in the game

If a case can be made, then sure. But we don't have endless room,
either, alas, so there will be cuts. Which is why IDEs are lower on the
priority list than a good editor that runs Ruby code on the push of a
button.

I just heard the sound of SCiTe

Marnen does bring up an interesting point. My idea is to give people
lots of choices. Marnen's idea is to direct people.
Going back to the documentation -- if the VM settles for an editor, then
the documentation can be directed at this editor, and possibly make
everything a lot more painless. I vote for redcar, half-jokingly,
half-serious: http://redcareditor.com/

I've started a Wave for the discussion of the editors and gems to add to
the RubyDev VM :
https://wave.google.com/wave/#restored:wave:googlewave.com!w%2BWsu54CnMI

I do think this thread is fine where it is but, as has been said before,
specifics shouldn't pollute this mailing list.

 

[Phillip Gawlowski]

Precisely why we should have at least one IDE. Maybe we can talk to the
Jetbrains people and have a limited version of Rubymine on there; but
that may be a little later in the game

Best would be one in native code, too. On a VM, performance starts to
matter again.

Marnen does bring up an interesting point. My idea is to give people
lots of choices. Marnen's idea is to direct people.

In an appliance, choices are *bad*. They are even worse for beginners.

Going back to the documentation -- if the VM settles for an editor, then
the documentation can be directed at this editor, and possibly make
everything a lot more painless. I vote for redcar, half-jokingly,
half-serious: http://redcareditor.com/

I'd even say roll our own: Top left a Tutorial, bottom left
Documentation (IntelliSense style, maybe), on the right the editor
buffer, with script output in a pop up window, all this in full screen mode.

 

[Marnen Laibow-Koser]

Aldric Giacomoni wrote:
[...]

Marnen does bring up an interesting point. My idea is to give people
lots of choices. Marnen's idea is to direct people.

[...]

Just to clarify my philosophy: I do generally believe in giving people
lots of choices. But I like to do it in such a way as to push them
gently in what seems to be the best direction to go in. Kind of like
what Rails does, in fact.

Best,

 

[Phillip Gawlowski]

Just to clarify my philosophy: I do generally believe in giving people
lots of choices. But I like to do it in such a way as to push them
gently in what seems to be the best direction to go in. Kind of like
what Rails does, in fact.

That's not at all what Rails does. Rails hits you over the head, drags
you back to its cave, and you *better* do things the Rails way.

Which worked out pretty well.

 

[David Masover]

Actually, you can, but you have to explicitly choose. I don't recall off
the top of my head, as I haven't looked in quite a while, but I believe
that Gentoo installs /usr/bin/ruby18 and /usr/bin/ruby19 (as well as
gem18 and gem19), and just toggles the /usr/bin/ruby symlink.

That's great, until your script wants to run some other script. Maybe the
"right way" would be to require it somehow, but maybe I just want my script to
do something like "system rake" or "system gem". Or maybe I've split my
program into several processes, but rather than actually forking, they're
distinct scripts.

The point is, in any of these scenarios, the Gentoo way could switch the ruby
interpreter out from under me.

So, while it's nice to be able to toggle the symlink, that's only a partial
solution. For a real solution, you'd want something like:

/usr/lib/ruby/1.8/bin/
/usr/lib/ruby/1.9.1/bin/

Toggle those in your paths, and have a just plain "ruby", "gem", "rake", etc
-- even install gem binaries in there (or wherever it ends up being).

Aside from that, it has the nice property of the switch being atomic --
there's no race condition where you might be running gem18 with the ruby19
interpreter (assuming gem18 has #!/usr/bin/ruby, but as above, you still want
to be confident that the "ruby" binary is the same ruby that you're running.)

 

[Mark T]

[Note: parts of this message were removed to make it a legal post.]

http://www.h-e-r-e-t-i-x.org/

... once hosted a Ruby 'distro'.

The init script was/is Ruby.

I did have it running in a Xen VM around two years back.

I wonder if it is powering .... http://www.h-e-r-e-t-i-x.org/download.htm

MarkT