Ruby Tool Survey

I'm running a survey to find out what tools Ruby and Rails people use. Explanation and (soon) results at http://www.tbray.org/ongoing/When/200x/2007/11/20/Ruby-IDE-Survey - the survey itself is at

http://www.surveymonkey.com/s.aspx?sm=GFR_2fGqqmOaL1zWDiuGhL0w_3d_3d

I'm not really well Rails-connected. Could I ask someone, as a favor, to relay the pointers over to Rails mailing-list land?

Thanks in advance, Tim

Well I took the survey but found it unsatisfying.

1) I'm a rails person who also does significant non-rails ruby
programming, but that wasn't an option.

2) Not a very wide tool selection, only editiors and an ide or two.
What about other tools, like rdebug, rspec, test/unit, .......

The overall ruby tools picture is broader than this. It's reminiscent
of a video recently published by one of the Smalltalk vendors which
compared the Smalltalk IDE to plain vanilla Rails development
following an introductory tutorial. While I'm sympathetic to the
Smalltalk POV, ruby/rails toolage HAS progressed past the early 80s.

···

On Nov 20, 2007 3:38 PM, Tim Bray <Tim.Bray@sun.com> wrote:

I'm running a survey to find out what tools Ruby and Rails people
use. Explanation and (soon) results at ongoing by Tim Bray
When/200x/2007/11/20/Ruby-IDE-Survey - the survey itself is at

http://www.surveymonkey.com/s.aspx?sm=GFR_2fGqqmOaL1zWDiuGhL0w_3d_3d

I'm not really well Rails-connected. Could I ask someone, as a
favor, to relay the pointers over to Rails mailing-list land?

Thanks in advance, Tim

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

I agree that the survey was limited, but why would one need anything
besides vim for Ruby development? :wink:

Let us know here when the results are up.

···

On Nov 20, 3:38 pm, Tim Bray <Tim.B...@Sun.COM> wrote:

I'm running a survey to find out what tools Ruby and Rails people
use. Explanation and (soon) results athttp://www.tbray.org/ongoing/
When/200x/2007/11/20/Ruby-IDE-Survey - the survey itself is at

http://www.surveymonkey.com/s.aspx?sm=GFR_2fGqqmOaL1zWDiuGhL0w_3d_3d

I'm not really well Rails-connected. Could I ask someone, as a
favor, to relay the pointers over to Rails mailing-list land?

Thanks in advance, Tim

i get this posting comments:

Insertion Failure

Error: Subsystem schema-validation initializer not started; exiting.

my comment:

"It is annoying to have to pick: I do a ton of both rails and non-rails work. I also do a ton of non-ruby work. I also work on vax, solaris, linux, osx and windows. That's why vim is the only choice - only it handles all this with aplomb whether locally or via a slow ssh connection. Vim + screen is the universal ide."

regards.

a @ http://codeforpeople.com/

···

On Nov 20, 2007, at 1:38 PM, Tim Bray wrote:

I'm running a survey to find out what tools Ruby and Rails people use. Explanation and (soon) results at ongoing by Tim Bray · Ruby Tool Survey - the survey itself is at

http://www.surveymonkey.com/s.aspx?sm=GFR_2fGqqmOaL1zWDiuGhL0w_3d_3d

I'm not really well Rails-connected. Could I ask someone, as a favor, to relay the pointers over to Rails mailing-list land?

Thanks in advance, Tim

--
we can deny everything, except that we have the possibility of being better. simply reflect on that.
h.h. the 14th dalai lama

Well I took the survey but found it unsatisfying.
--
Rick DeNatale

Agreed. I'd be curious to see a much more comprehensive survey.
Testing behavior, operating systems, alternate interpreters (jruby),
GUIs, web servers. Sure, you can get a pretty good sense from the
mailing list, but you gotta love statistics.

Daniel Brumbaugh Keeney

i also *need* screen. because i worked remotely on at least a dozen machines over the course of a given week i find it critical to be to detach a vim session and pick up where i left off and also to multiplex terminals, otherwise i'd have 30 or more open. screen + vim is the ultimate ide, it even works with c and fortran. gasp!

a @ http://codeforpeople.com/

···

On Nov 21, 2007, at 6:45 AM, Brian Adkins wrote:

I agree that the survey was limited, but why would one need anything
besides vim for Ruby development? :wink:

--
it is not enough to be compassionate. you must act.
h.h. the 14th dalai lama

Well I took the survey but found it unsatisfying.

1) I'm a rails person who also does significant non-rails ruby
programming, but that wasn't an option.

:wink:

2) Not a very wide tool selection, only editiors and an ide or two.
What about other tools, like rdebug, rspec, test/unit, .......

Tim's blog provides a bit more context:

   At Sun, I'm in the Developer Tools group. Someone asked "Which tools
   does the Ruby gang use, anyhow?" I said "Hmm, TextMate, Emacs, Vi,
   recently some Eclipse and NetBeans." They said "How do you know?" I
   said "Uh." They said "Why don't you ask?" So I am. Drop by the Ruby
   Tool Survey and let's find out. There are only two questions; if it takes
   you more than fifteen seconds there's something wrong. I promise to
   publish all the results in full right here in this entry once I have them
   at the end of the month.

http://www.tbray.org/ongoing/When/200x/2007/11/20/Ruby-IDE-Survey

It's imperfect and limited, but it's not supposed to be a State of the
Developer, but a temperature gauge and that's it.

-austin

···

On 11/20/07, Rick DeNatale <rick.denatale@gmail.com> wrote:
--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

Nice tip on screen. My need is not as great, but there have been times
when it would've been useful, so I just read up on it.

···

On Nov 21, 11:01 am, "ara.t.howard" <ara.t.how...@gmail.com> wrote:

On Nov 21, 2007, at 6:45 AM, Brian Adkins wrote:

> I agree that the survey was limited, but why would one need anything
> besides vim for Ruby development? :wink:

i also *need* screen. because i worked remotely on at least a dozen
machines over the course of a given week i find it critical to be to
detach a vim session and pick up where i left off and also to
multiplex terminals, otherwise i'd have 30 or more open. screen +
vim is the ultimate ide, it even works with c and fortran. gasp!

Brian,
I could use "screen". Can you tell me where you "read up on it"? I've
looked on the web, but didn't find anything relevant. I'd like to know
how to use it so I can leave work and pick up a session at home.
Thanks,
PV

Brian Adkins wrote:

···

On Nov 21, 11:01 am, "ara.t.howard" <ara.t.how...@gmail.com> wrote:

On Nov 21, 2007, at 6:45 AM, Brian Adkins wrote:

> I agree that the survey was limited, but why would one need anything
> besides vim for Ruby development? :wink:

i also *need* screen. because i worked remotely on at least a dozen
machines over the course of a given week i find it critical to be to
detach a vim session and pick up where i left off and also to
multiplex terminals, otherwise i'd have 30 or more open. screen +
vim is the ultimate ide, it even works with c and fortran. gasp!

Nice tip on screen. My need is not as great, but there have been times
when it would've been useful, so I just read up on it.

--
Posted via http://www.ruby-forum.com/\.

Brian,
I could use "screen". Can you tell me where you "read up on it"? I've
looked on the web, but didn't find anything relevant. I'd like to know
how to use it so I can leave work and pick up a session at home.
Thanks,
PV

man screen

and/or

Google (screen)

The main tip I read was to use <ctrl>-a d to "detach" from the screen
session. Then invoke "screen -x" to re-attach.

···

On Nov 24, 8:26 am, Peter Vanderhaden <bostonanti...@yahoo.com> wrote:

Brian Adkins wrote:
> On Nov 21, 11:01 am, "ara.t.howard" <ara.t.how...@gmail.com> wrote:
>> On Nov 21, 2007, at 6:45 AM, Brian Adkins wrote:

>> > I agree that the survey was limited, but why would one need anything
>> > besides vim for Ruby development? :wink:

>> i also *need* screen. because i worked remotely on at least a dozen
>> machines over the course of a given week i find it critical to be to
>> detach a vim session and pick up where i left off and also to
>> multiplex terminals, otherwise i'd have 30 or more open. screen +
>> vim is the ultimate ide, it even works with c and fortran. gasp!

> Nice tip on screen. My need is not as great, but there have been times
> when it would've been useful, so I just read up on it.

--
Posted viahttp://www.ruby-forum.com/.

One pretty good source of getting started material is:

James Edward Gray II

···

On Nov 24, 2007, at 7:26 AM, Peter Vanderhaden wrote:

I could use "screen". Can you tell me where you "read up on it"?

Brian Adkins wrote:

···

On Nov 24, 8:26 am, Peter Vanderhaden <bostonanti...@yahoo.com> wrote:

Brian,
I could use "screen". Can you tell me where you "read up on it"? I've
looked on the web, but didn't find anything relevant. I'd like to know
how to use it so I can leave work and pick up a session at home.
Thanks,
PV

man screen

and/or

Google (screen)

The main tip I read was to use <ctrl>-a d to "detach" from the screen
session. Then invoke "screen -x" to re-attach.

It always amazes me every time someone doesn't know about screen. Back in the day it was absolutely indispensable. Now that I have a terminal window with tabs it's not as big a deal, but I still use it on remote servers.

- Charlie

these are the aliases i use most often from the command line

cfp:~ > grep screen .bash_profile
     alias sl='screen -list '
     alias sdr='screen -d -r '
     alias s='screen -D -R '

these allow me to start a named screen with, for example

cfp:~ > s attributes

and then to list them, viewing the names with

cfp:~ > sl
There are screens on:
         2364.attributes-5.0.0 (Attached)
         2611.systemu-1.2.0 (Attached)
         4131.orderedhash-0.0.3 (Attached)
         554.bj-0.0.1 (Attached)
         747.main-2.6.0 (Attached)

and to re-attach to a named screen with

cfp:~ > sdr attributes

which dumps me exactly where i was several days ago working on the project

on my mac it use iterm and keep one tab per project, with each tab containing a screen that itself contains all the goings on for that project, for example and edit window, one running ./script/console, one tailing a log file, etc. with this approach it's quite easy to have 10 or 20 projects, some rails, some ruby, some c, some perl, all open in the same 'ide' with the same interface.

maybe i'll put together a screencast (no pun intended) at some point to give a visual of what this is like to work in.

cheers.

a @ http://codeforpeople.com/

···

On Nov 24, 2007, at 10:10 AM, Brian Adkins wrote:

man screen

and/or

Google (screen)

The main tip I read was to use <ctrl>-a d to "detach" from the screen
session. Then invoke "screen -x" to re-attach.

--
we can deny everything, except that we have the possibility of being better. simply reflect on that.
h.h. the 14th dalai lama

I use screen + vim + rails.vim. I'm in heaven. If you haven't seen
rails.vim, check it out:

http://rails.vim.tpope.net/

···

On Nov 26, 2007 2:17 PM, James Edward Gray II <james@grayproductions.net> wrote:

On Nov 24, 2007, at 7:26 AM, Peter Vanderhaden wrote:

> I could use "screen". Can you tell me where you "read up on it"?

One pretty good source of getting started material is:

The Gentoo Linux | CustomEssayMeister.com

James Edward Gray II

maybe i'll put together a screencast (no pun intended) at some point
to give a visual of what this is like to work in.

+1

···

--
Giles Bowkett

Podcast: http://hollywoodgrit.blogspot.com
Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
Tumblelog: http://giles.tumblr.com

> maybe i'll put together a screencast (no pun intended) at some point
> to give a visual of what this is like to work in.

+1

just to expand on my own plus 1, I've been obsessing over tools
recently - fixing up my IRB enhancements, learning emacs, going back
to the TextMate book for all the stuff I missed, upgrading from grep
to ack, getting roasted alive for daring to criticize debuggers, etc.,
etc.

(one surprising thing: reading the emacs Lisp for the Ruby syntax
coloring support. I was much less enthused than I had expected to be -
hundreds of lines of code, none of the OO structure I'm used to - I've
seen Perl that was easier to read, at least in the "table of
contents"/"which sections do what" sense.)

anyway, I was always a vi guy, but then I switched to TextMate, but
then I got tired of it and started looking into emacs, and for sheer
power it looks like the king. so a screencast on features of vi I
didn't know about is definitely very useful to me.

···

--
Giles Bowkett

Podcast: http://hollywoodgrit.blogspot.com
Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
Tumblelog: http://giles.tumblr.com

http://drawohara.tumblr.com/post/20284516

the quality sux but the conversion to flv was blowing up on my box - i'll try again tomorrow. until the low-quality version and link to full res is here.

just a quick overview - but maybe it gives the flavour.

cheers.

a @ http://codeforpeople.com/

···

On Nov 25, 2007, at 5:24 PM, Giles Bowkett wrote:

maybe i'll put together a screencast (no pun intended) at some point
to give a visual of what this is like to work in.

+1

--
we can deny everything, except that we have the possibility of being better. simply reflect on that.
h.h. the 14th dalai lama

Giles Bowkett wrote:

(one surprising thing: reading the emacs Lisp for the Ruby syntax
coloring support. I was much less enthused than I had expected to be -
hundreds of lines of code, none of the OO structure I'm used to - I've
seen Perl that was easier to read, at least in the "table of
contents"/"which sections do what" sense.)

Emacs and Lisp are so tightly interbred from many decades of co-use that

a. Unless you know Lisp fairly well, it's tough to hack on emacs, and
b. It's tough to find a better editor for Lisp.

Hard-core Lisp programmers probably are incapable of using an IDE other than emacs anyway. :slight_smile: I never learned emacs -- I was told that it was a memory hog, and since I wasn't getting paid to develop Lisp, I used the editor I was given rather than force the issue.

anyway, I was always a vi guy, but then I switched to TextMate, but
then I got tired of it and started looking into emacs, and for sheer
power it looks like the king. so a screencast on features of vi I
didn't know about is definitely very useful to me.

Well ... there's "vi" and then there's Vim 7.x. :slight_smile: The original vi is a nice, compact, regular-expression-based visual editor that will function well on a dumb terminal. Vim 7.x, on the other hand, has a lot of new features, including GVim, a semi-happy marriage of vim and a Notepad-like GUI editor. Vim 7.x is probably close to the feature count of emacs by now, while the original vi was something you could learn just about all of in an afternoon.

To throw another monkey wrench into the discussion, I rather like SciTe. The underlying "scintilla" widgets integrate well with scripting languages like Ruby and Python, and it's cross-platform.

···

very cool.

My favorite part is the first 5 seconds. Bottom right shows ara's
face. Opening dialog: "alright .. ::takes swig of beer bottle:: .."
[1]

Your workflow is indeed very close to mine! :wink:

btw, screen and vim are also very critical tools for me. I've
currently cycled out of iterm, though.

Cameron

[1] to be fair, I can not see a label -- so it could just be root beer
or the like.

···

On 11/27/07, ara.t.howard <ara.t.howard@gmail.com> wrote:

On Nov 25, 2007, at 5:24 PM, Giles Bowkett wrote:

>> maybe i'll put together a screencast (no pun intended) at some point
>> to give a visual of what this is like to work in.
>
> +1

http://drawohara.tumblr.com/post/20284516

the quality sux but the conversion to flv was blowing up on my box -
i'll try again tomorrow. until the low-quality version and link to
full res is here.

just a quick overview - but maybe it gives the flavour.

Giles, have you ever tried tabs in Vim? IMHO it's a lot easier to
manage multiple tabs than multiple windows in Vim.

And for screen, try `screen -S session-name` to name the screen
sessions you create so when you do `screen -ls` it's easier to
remember which session is which. Then you can resume a session with
`screen -r session-name` too.

Also great for Vim is the taglist.vim plugin, which lets you see a
method/member summary of the file you're editing in a vertical window
to the left (or anywhere else through config options). It works with
most languages, including Ruby.

This setup really helps me focus on my work since I can make my
terminal fullscreen (and command-tab or alt-tab to Firefox if
necessary). I like how much lighter weight Vim+screen is than a GUI
and that I can keep a single screen session going for months on my
servers.

Great video.

···

On Nov 26, 2007 2:45 AM, Giles Bowkett <gilesb@gmail.com> wrote:

> > maybe i'll put together a screencast (no pun intended) at some point
> > to give a visual of what this is like to work in.
>
> +1

just to expand on my own plus 1, I've been obsessing over tools
recently - fixing up my IRB enhancements, learning emacs, going back
to the TextMate book for all the stuff I missed, upgrading from grep
to ack, getting roasted alive for daring to criticize debuggers, etc.,
etc.

(one surprising thing: reading the emacs Lisp for the Ruby syntax
coloring support. I was much less enthused than I had expected to be -
hundreds of lines of code, none of the OO structure I'm used to - I've
seen Perl that was easier to read, at least in the "table of
contents"/"which sections do what" sense.)

anyway, I was always a vi guy, but then I switched to TextMate, but
then I got tired of it and started looking into emacs, and for sheer
power it looks like the king. so a screencast on features of vi I
didn't know about is definitely very useful to me.

--
Giles Bowkett

Podcast: http://hollywoodgrit.blogspot.com
Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
Tumblelog: http://giles.tumblr.com