Best ways to accelerate Ruby's popularity

[Dick Davies]

I would like that, and have taken some stabs at writing a wrapper that
would allow comments on arbitrary HTML pages, but have gotten
sidetracked by numerous other projects.

How abitrary? I found http://wikalong.org the other day, thought it was
a brilliant idea...

 

[James Britt]

How abitrary? I found http://wikalong.org the other day, thought it was
a brilliant idea...

Hey, this looks quite neat. Downside is that it requires a specific
browser. But that's sort of the general idea.

Ideally (and this is a JavaScript/HTML DOM thing I expect) I would like
to be able to associate comments with specific paragraphs. So that, for
example, if there were an online Ruby manual, one could click on a
paragraph, get a pop-up thingy, and add a note or correction for that
paragraph. And the HTML would be dynamically modified when rendered to
indicate were there were comments.

James

 

[Ben Giddings]

Did you factor making love into that? Titanium is rather hard...

If the messages bombarding my junk-mail-inbox, the ads I see constantly
on TV, the magazine ads, the movie tie-ins, and the satellite-beamed
mood-control rays are any indication, "hardness" is something that human
males are not capable of achieving, at least not the perfect hardness
that "she" (whoever she may be) desires.

I see my titanium as a distinct advantage. And if it isn't enough, I'm
sure I can powder-coat my titanium body with c14l1s, or v14gr@ or
whatever the newest one is.

Ben

 

[Ilmari Heikkinen]

Ideally (and this is a JavaScript/HTML DOM thing I expect) I would
like to be able to associate comments with specific paragraphs. So
that, for example, if there were an online Ruby manual, one could
click on a paragraph, get a pop-up thingy, and add a note or
correction for that paragraph. And the HTML would be dynamically
modified when rendered to indicate were there were comments.

James

Something like this?

http://fhtr.org/kig/dev/selection_test4.html (click on paragraphs)

Works in firefox/moz only, the code and the layout need a stab in the
head to put them out of their collective misery, but the idea is
similar to what you're after I think.

Oh and there is no backend there, it's all client-side, nothing gets
saved.

 

[Ben Giddings]

An idea is to group the sites in an OSTG-like bar.
( cf. the top of the page on slashdot.org )
This bar would be on every linked site of the bar, so that the
connection between the sites would be more evident.

I think this is a good idea, if all the sites shared a common header of
some kind, that would help a lot. If nothing else, it gives you an idea
how much you should trust some of the sites.

I still think it's an even better idea to put them all under a domain
umbrella, be it ruby.org or ruby-lang.org or whatever, but anything like
that is a step in the right direction.

Ben

 

[Ben Giddings]

Serving from the same machine is one thing; servicing requests when the
sites are on physically distinct machines, under separate administrative
control, is another. I don't know enough about Apache to say for sure;
it may be enough to engineer redirects to other sites so that a request
for docs.ruby.org (or whatever) lands you on www.ruby-doc.org.

Right, but it would all be the same machine.

Say the sites are currently set up as follows:
www.ruby-lang.org has the IP address 192.168.0.1
*.rubyforge.org has the IP address 192.168.0.2
*.ruby-doc.org has the IP address 192.168.0.3
...

All you'd have to do is adjust the DNS entries for ruby-lang.org so
that, for instance, rubyforge.ruby-lang.org pointed to 192.168.0.2.

The web server on the 192.168.0.2 machine would then have have to
respond to requests for either *.rubyforge.org or
rubyforge.ruby-lang.org. In apache, this is normally easy to set up,
though occasionally some web-based apps require a server name to be set,
to be used in self-referential URLs, so someone might come in on
rubyforge.ruby-lang.org, but would end up with their browser displaying
www.rubyforge.org. But, I don't think that's a big deal.

All that's required is that the DNS system know that www.ruby-doc.org
and ruby-doc.ruby-lang.org (or docs.ruby-lang.org, or all of the above)
all point to the same IP address, and then that the server listening on
that IP know what to do with the requests.

Ben

 

[David A. Black]

HI --

I think this is a good idea, if all the sites shared a common header of some
kind, that would help a lot. If nothing else, it gives you an idea how much
you should trust some of the sites.

I wouldn't want to think that a Ruby site I created would necessarily
be considered untrustworthy because it didn't have a particular
navigation bar. Maybe those sites that want to join together can do
so, but embrace an open-ended model when it comes to growth and
initiative and trust


David

 

[Thursday]

...
Ruby will stand or fall on its own merits.
...
... I've been writing software since 1981, starting with 6502 assembler
on a VIC-20.
...
Stephen

As a former user of a Commodore computer, have you already forgotten
about how the then-excellent Amiga fared on its merits in the 90s?
Preemptive multitasking, 4096 colors, great sound, sprites, etc. vs the
PC running MSDOS + Windows 3.1 in 256 colors... Amiga got its ass kicked.

Sadly, branding, marketing, company reputation, momentum and perception
can have a lot more to do with how a product/technology fares than
actual merits...I sincerely wish I was wrong about this but there are
too many examples that prove this to be true.

A few quick hits can do a lot of good for Ruby without much time investment.

 

[Ben Giddings]

I wouldn't want to think that a Ruby site I created would necessarily
be considered untrustworthy because it didn't have a particular
navigation bar. Maybe those sites that want to join together can do
so, but embrace an open-ended model when it comes to growth and
initiative and trust

Ok, maybe not "trustworthiness", but maybe "officialishness", or
"officialocity" or some other similar word that my english teacher would
faint if she heard me using?

I'll tell you where I'm coming from. Say I'm new to the language and
want some documentation on something in the standard library, say
"webrick". Although it's part of the standard library, when I search
around on the official ruby site, I can't find out anything about it, so
I go to Google and search for it, and find a site... only that site
doesn't seem to be a very official Ruby site...

I can maybe trust the documentation there, but how do I know that I'm
not going to be bombarded by popups on that site, or that the site isn't
some historical thing from before webrick became part of the official
distribution, or what?

(of course, I'm not picking on webrick now, I'm just trying to show the
problem with random, open, enthusiast-driven sites).

I think it would really help if, when something is adopted into the
standard library, there were an effort made to adopt the website and
documentation as well, so that it was clear to everybody that this is no
longer just some ruby hacker's pet project, but an official part of Ruby.

The same basic concept applies to ruby-doc.org. Is this just some fan's
attempt to document Ruby, which may be incomplete or out of date, or is
this the actively maintained Ruby documentation?

See my concerns?

Ben

 

[Stephen Kellett]

mood-control rays are any indication, "hardness" is something that
something that human males are not capable of achieving, at least not
the perfect hardness that

I wasn't thinking of that type of hardness.

I was thinking tender stroking, caressing, bodies next to each other
kind of thing. Titanium is a bit of disadvantage in this situation

Stephen

 

[Stephen Kellett]

As a former user of a Commodore computer, have you already forgotten
about how the then-excellent Amiga fared on its merits in the 90s?
Preemptive multitasking, 4096 colors, great sound, sprites, etc. vs the
PC running MSDOS + Windows 3.1 in 256 colors... Amiga got its ass
kicked.

I remember the 1980s, not sure about the 1990s. In the 1990s it gots its
ass kicked for one reason. Versus the Atari ST, it was overpriced. Jack
Tramiel got the pricing right and the ST ruled. I'd love to have had an
Amiga. I just could not afford one.

I don't remember the ST or the Amiga featuring much in the 1990s - the
PC had started to get sufficiently cheap for people to be interested in
that. That said, the last computer game I wrote was for the Atari ST and
the 80286 AT in 1988. I lost interest in games after that - I had
embedded systems and Unix boxes to play with. This may explain my lack
of recollection for that era.

Sadly, branding, marketing, company reputation, momentum and
perception can have a lot more to do with how a product/technology fares
than actual merits...I sincerely wish I was wrong about this but there are
too many examples that prove this to be true.

I agree. However my comment was more the case of I've seen very few
arguments against Ruby that seem to hold much water (hence I think it
will succeed on its merits). I've just found out why blocks are useful -
nice idea (I only got my pickaxe book yesterday).

The ArachnoRuby people and Software Verification are both commercial
companies providing software tools for Ruby. This must help - visitors
to their websites looking for tools for one language will notices the
tools for the other languages.

I can't say much about ArachnoRuby, but Software Verification get people
visiting them for C++ tools etc, and people see other tools for Python
and Ruby. That alone is causing interest. I'd expect the same is true of
the people that go looking for ArachnoPerl or ArachnoPython.

The actual language, well people seem to really get it, once they get
it. I've typically always written a C++ GUI app for any scripting type
application - I've never liked Perl (my Perl book is still unread),
Python seems good, but I hate the stupid errors you get from that
appalling indentation scheme. Ruby looks interesting, I've bought the
Pragmatic Pick Axe book and like what I've seen so far.

A Ruby to Binary executable is all you need (if it doesn't already
exist) and those afraid of (but they'll see my source) will have no
reason to fear Ruby.

I think if Ruby was promoted more on Windows you'd get more mileage.
I've been a Linux user since 1994 and Unix guy since 1990. In 1996 I
started working on Windows and seem to have been there ever since. Thats
just the way your career goes. I was a rabid anti-MS person until I
started using MSDN. The quality of the documentation and sheer volume of
resources - its very good. I digress. There are a lot more people
writing software on Windows platforms - you need to somehow attract them
- I get the impression that this newsgroup is mainly Linux users.

Windows platforms - many people resort to batch files or if they know
better, Perl or Python.

Also, Ruby seems easy to learn. It would be a good language to start
with - so again you've got a much larger audience with Windows.

Changing tack slightly. In the embedded space, Linux is the rising star
- I don't see that changing, no one is going to spend on Windows CE or
Windows XP embedded licensing fees. If Ruby was made more robust you
could become a useful embedded scripting language.

More Robust:
When calling Ruby from C, none of the Ruby functions should call
exit (or ExitProcess, etc) for any reason. If there is an error
it
should be handled with an error code or an exception, whichever
is appropriate.

Have done some embedded work with Ruby, it is not a pleasant
experience from the C API. Some Ruby calls deliberately call
exit() - hence you have to code your way around them. Other
calls
just seem to crash if you have wrong arguments, rather than
gracefully return with an error code.

Either way I fixed up what I needed and can't remember what the
problems were other than I found a way around them (which is
what was needed as my task was to work with the current
distribution, not require customers to fix their distribution).

Well, I've written far more than I expected to.
Summary:
Ruby -> Executable.
Encourage use by Windows users (even if you dislike Windows).
Make more robust and thus suitable for embedded space.

Stephen

 

[Tim Hunter]

I wasn't thinking of that type of hardness.

I was thinking tender stroking, caressing, bodies next to each other
kind of thing. Titanium is a bit of disadvantage in this situation

I've heard of "off-topic" before, but jeez, guys, go take a shower or
something...

 

[James Britt]

Something like this?

http://fhtr.org/kig/dev/selection_test4.html (click on paragraphs)

Yes, that's a good approximation of what I had in mind.

Some years back, when IE5 was cutting edge, I wrote some nice
JavaScript+ASP stuff to allow virtual post-it notes on a web page.

I believe that the DHTML capabilities of Firefox/Mozilla are now such
that writing a cross-browser version, even with just basic features,
would be quite do-abale. Add in the "back by popular demand"
XmlHttpRequest object, and server persistence would be a snap.



James

 

[James Britt]

Right, but it would all be the same machine.

What is the "it" that would all be on the same machine? The DNS
configuration, or the sites themselves? Or both?

James

 

[James Britt]

HI --




I wouldn't want to think that a Ruby site I created would necessarily
be considered untrustworthy because it didn't have a particular
navigation bar. Maybe those sites that want to join together can do
so, but embrace an open-ended model when it comes to growth and
initiative and trust

The idea of some sites being "official" ,while others aren't, difficult.

I understand the value of branding, and how a common "look" can (often)
reduce confusion. But any look can be outright copied, so simply having
a logo or banner means little.

Trust tends to come from a network effect. If I determine one site to
be trustworthy (say, ruby-lang.org), and it links to another site
(rubyforge.org), I can infer that that other site is probably worthwhile.

That says far more to me than any logo or banner.

I don't see any shortcuts for people to figure out what sites are
reliable sources and which aren't. A stamp of approval won't do it.

James

 

[tdgrmsn]

Hello all, short-term lurker, first-time poster.

Python went through this discussion about a year ago (and probably many
times before and since), and it can get ugly. The "branding/marketing"
supporters vs. "technical merits/docs/has to be perfect in Lynx"
supporters situation can get very contentious. That said, you people
seem a bit more friendly than c.l.py so maybe that won't happen <g> (to
be fair there were plenty of very nice people too..). The "too many web
frameworks?" also came up, though due to userbase size and visibility
of Rails it seems less of an issue in Ruby.

Also, I'd suggest splitting off design/appearance/etc concerns from
DNS/etc. if possible. There is/was a python-marketing list that was
discussing the whole thing too, to keep traffic off of the main list.
Maybe that would help here, I don't know.

Anyhow, here's a bit I posted then that I think is relevant here:

=================

So, regarding uh, *python*, I'm thinking perhaps a more useful
direction and way to corral this tangent is putting together a short
list of general (potential) user types - complete newcomers, dabblers
in perl/php, experienced devs, etc.

Related to this, and a key part of the site design/layout Ive lacked
time to do so far is a good overview of industries/fields using
python. My first thought is a (much shorter) Yahoo!-esque directory,
titled

"Using Python For..."

Web Programming Education
(CGI, App Servers, etc) (Teaching programming,class texts,&c)

Scientific Graphical Interfaces (GUI)
(genome, biochem, &c) (wx, tk, etc.)

Networking Statistical/Financial
(servers, sockets, etc) (numeric, financial libs, etc)

and so on. Granted this type of list could be sliced and diced many
ways, but overall I think is a really good way to pull people
in. Perl.com has a list like this though, it's now(?) alphabetical and
a bit difficult to use I think.

Also (vaguely) relating to the above discussion, if you're working
for a financial firm and need info on finance libs and apps, being
able to eliminate the 8 zillion other things python does well and go
straight to your need, you are in a way eliminating that other
noise/distraction/confusion and simplifying the decision/edification
of the viewer.

=================

This idea seemed to get a decent reception from both "sides", so maybe
it would be useful for Ruby as well.

-T

 

[ToddG]

Sorry, re-post. Still getting used to this web interface...:

Hello all, short-term lurker, first-time poster.

Python went through this discussion about a year ago (and probably many
times before and since), and it can get ugly. The "branding/marketing"
supporters vs. "technical merits/docs/has to be perfect in Lynx"
supporters situation can get very contentious. That said, you people
seem a bit more friendly than c.l.py so maybe that won't happen <g> (to
be fair there were plenty of very nice people too..). The "too many web
frameworks?" also came up, though due to userbase size and visibility
of Rails it seems less of an issue in Ruby.

Also, I'd suggest splitting off design/appearance/etc concerns from
DNS/etc. if possible. There is/was a python-marketing list that was
discussing the whole thing too, to keep traffic off of the main list.
Maybe that would help here, I don't know.

Anyhow, here's a bit I posted then that I think is relevant here:

=================

So, regarding uh, *python*, I'm thinking perhaps a more useful
direction and way to corral this tangent is putting together a short
list of general (potential) user types - complete newcomers, dabblers
in perl/php, experienced devs, etc.

Related to this, and a key part of the site design/layout Ive lacked
time to do so far is a good overview of industries/fields using
python. My first thought is a (much shorter) Yahoo!-esque directory,
titled

"Using Python For..."

Web Programming Education
(CGI, App Servers, etc) (Teaching programming,class texts,&c)

Scientific Graphical
Interfaces (GUI)
(genome, biochem, &c) (wx, tk, etc.)

Networking Statistical/Financial
(servers, sockets, etc) (numeric, financial libs, etc)

and so on. Granted this type of list could be sliced and diced many
ways, but overall I think is a really good way to pull people
in. Perl.com has a list like this though, it's now(?) alphabetical and
a bit difficult to use I think.

Also (vaguely) relating to the above discussion, if you're working
for a financial firm and need info on finance libs and apps, being
able to eliminate the 8 zillion other things python does well and go
straight to your need, you are in a way eliminating that other
noise/distraction/confusion and simplifying the decision/edification
of the viewer.

=================

This idea seemed to get a decent reception from both "sides", so maybe
it would be useful for Ruby as well.

-T

 

[James Britt]

Ok, maybe not "trustworthiness", but maybe "officialishness", or
"officialocity" or some other similar word that my english teacher would
faint if she heard me using?
...

(of course, I'm not picking on webrick now, I'm just trying to show the
problem with random, open, enthusiast-driven sites).

Hmm, That seems to describe most Ruby sites right now. Maybe not so
random, but open andenthusiast-driven.

I think it would really help if, when something is adopted into the
standard library, there were an effort made to adopt the website and
documentation as well, so that it was clear to everybody that this is no
longer just some ruby hacker's pet project, but an official part of Ruby.

The same basic concept applies to ruby-doc.org. Is this just some fan's
attempt to document Ruby, which may be incomplete or out of date, or is
this the actively maintained Ruby documentation?

See my concerns?

Sure. First, it would be tremendous help if every library shipped in
the standard distro included, if not full docs, at least a page
explaining where to find full docs, then users would have a means of
finding the extra docs they need. (Maybe a documentation index page for
the distro would be good.)

As for ruby-doc.org (and any other site, really), mere appearances tell
you nothing. A link to ruby-doc.org from a trusted site is better than
a nice logo.

To some extent, new users are going to have to do a least some amount of
leg work. They should read FAQs, read news groups, and ask questions.

The Ruby community should always be mindful of this, and try to keep the
amount of random browsing to a minimum, but I don't see many ways to
assure authenticity of sites and content that don't make the job of
running these sites harder than it is.


James

 

[Ilmari Heikkinen]

Not at the moment. Those doc pages are generated from rdoc, and the
anchors to method names a re abstract strings, not the method names
themselves. So you get this:

http://www.ruby-doc.org/core/classes/Enumerable.html#M001864

You need to know that M001864 is the 'map' method.

Yes, the way I see this, the issue can be worked around by either:
a) adding an extra degree of indirection (ie. search)
- because there might be Class.new and Class#new, which one does
Class.html#new go to?
- Class.new -> find/Class.new, Class#new -> find/Class%23new

or b) adding extra structure to the anchor tags
- Class.new -> Class.html#cm_new, Class#new -> Class.html#im_new

Depends. How often would there be requests, and by how many people?
Put another way, how does this differ from people viewing the pages
directly in a browser to help them while coding?

Would probably be less requests per person using context-help vs. using
navigation:
* String.help:reverse goes directly to String.html
* Through navigation it's 3 requests (index, core api, string).

Of course, I can't know if it changes browsing habits (use help more
because it's easy, thus generate more total requests.)

I don't see a problem. In general, I like the idea of serving up data
services for remote applications, though in practice I would have to
see how the bandwidth goes if ruby-doc had a more direct Web API for
accessing documentation. (Though the data format should be something
other than HTML 4.)

Another way would be to generate and use local static doc package. I
think I'll have to add support for that too.. it'd lose the possible
community aspect, but gain off-line capability.

No, I think I understand. It is a problem that one cannot easily
locate and/or bookmark specific methods and classes. The framed view
of the docs is handy for certain things, but not others. And allowing
comments on the docs would be sweet.

Yes, exactly.

 

[Curt Hibbs]

I understand the value of branding, and how a common "look" can (often)
reduce confusion. But any look can be outright copied, so simply having
a logo or banner means little.

Trust tends to come from a network effect. If I determine one site to
be trustworthy (say, ruby-lang.org), and it links to another site
(rubyforge.org), I can infer that that other site is probably worthwhile.

That says far more to me than any logo or banner.

I don't see any shortcuts for people to figure out what sites are
reliable sources and which aren't. A stamp of approval won't do it.

I can't quite figure out where you stand from these comments.

I think that despite the fact that a common "look" would not solve the
problem determining a site's reliability, it *will* (as you said) reduce
confusion. For me, this is a big issue and should be done.

Improving the reliability, content, and organization of various sites is
also important and should be done.

I see these are mutually beneficial, parallel efforts.

Curt