google 'rpa' (ruby production archive). for some reason, it didn't take off
like gems - imho it was a powerful idea...
cheers.
-a
···
On Mon, 9 Oct 2006, Tim Uckun wrote:
I took a brief look at activemessaging. Looks great. Then I take a
look at the roadmap and see that all the tickets logged are actually
spam.
No tickets logged, no milestones defined. I take a look at the
timeline and it's all spam too so no code checked in either.
To me this is one of the biggest frustrations of dealing with ruby and
rails. The libraries are in a unfinished state and are not being
worked on actively. Examples.
The DBI ADO library is b0rked. The answer seems to be to use ODBC. I
volunteered to work on the libraries if somebody could integrate my
work with DBI but nobody is interested.
I was excited about railscron and it's been dumped and replaced with
something which has no cron functionality at all (threading problems
from what I can gather).
I tried various AGI implementation for asterisk and the same story.
RAGI hasn't been touched in a year, the rubyforge forums questions go
unanswered, patches that were submitted are not integrated, bugs not
fixed, etc.
I don't know what the answer is. I am grateful that talented people
have dedicated their time and effort to create these libraries in the
first place but it's very hard to tell which libraries are robust,
which ones are abandoned, which ones are not being worked on because
they are stable and don't need any more work.
--
in order to be effective truth must penetrate like an arrow - and that is
likely to hurt. -- wei wu wei
Also, the overgeneralising vaguely to nag at [insert name of language
that isn't Ruby here] doesn't quite make me trust you more as a
technology journalist. It comes across as so much cheap
community-pandering.
If you have nothing good to say...
David Vallner
(Can we -finally- stop with the cheap shots at not-Ruby?)
I stand by my point, expressed in the InfoQ piece, that there are several
areas of enterprise infrastructure that are lacking in demonstrable ways.
One of them is message-queueing, a core technology for application
integration that is, in my opinion, seriously underused due to lack of real
understanding of its capabilities, and also challenges with the available
tools. Most of the enabling technology used in message-oriented integration
today is proprietary and not open, frighteningly expensive, and not
interoperable (by design). ActiveMQ is a very valuable, impressive, and
competent step in the direction of opening things up. I won't try to
convince you or anyone else that ActiveMQ is not suitable for all uses, and
that there is room for an alternative or two. Why should Rubyists consider
creating such an alternative? Because of Ruby's unique attributes, and also
because of the stylistic conventions that have evolved in our community, a
Ruby-based alternative may be better in measurable and meaningful ways,
particularly regarding ease of deployment, configurability, and integration
with other technologies. One size doesn't necessarily fit all.
What are my qualifications to say things about message-queueing that you
don't want to hear? I've designed several commercial MQ systems over the
last ten years that have met with commercial success. I've designed both
wire protocols and APIs for MQ, going back long before JMS or Jabber were
invented. I come to this forum to learn new things that I didn't know
before. You haven't said anything that qualifies so far, but I'm still
listening.
···
On 10/6/06, David Vallner <david@vallner.net> wrote:
> And has it seen much production use? Hard to tell from the website.
The Stomp connector for ActiveMQ has seen a lot of use (and has grown
the knobs that accompany).
The ruby connector has fewer war stories, but has served me and a
couple others fairly well so far. Not sure the extent of its use. The
protocol is downright trivial, so adjusting a client is pretty
straightforward (I think).
Well, after playing around for only an hour I managed to run into this
bug in activemq when using stomp. Basically, if a consumer
disconnects in a bad way the broker can get stuck, and you'll never
see your messages.
Well, after playing around for only an hour I managed to run into this
bug in activemq when using stomp. Basically, if a consumer
disconnects in a bad way the broker can get stuck, and you'll never
see your messages.
Better yet: don't. Better to use a Wiki that does other proactive
stuff. Most CAPTCHA implementations wouldn't even remotely pass any
disability testing.
-austin
···
On 10/29/06, Tim Uckun <timuckun@gmail.com> wrote:
I googled RPA and all I got was a wiki filled with spam.
Here is a suggestion for people running wikis and trac.
I was using 4.0.1. But 4.0.2 is even worse. In addition to the bug
still being there, activemq has a memory leak, at least on freebsd,
and I ran into another bug where it hangs on shutdown. Definitely not
ready for production use by my standards.
Chris
···
On 10/7/06, Brian McCallister <brianm@apache.org> wrote:
On Oct 7, 2006, at 1:24 AM, snacktime wrote:
> Well, after playing around for only an hour I managed to run into this
> bug in activemq when using stomp. Basically, if a consumer
> disconnects in a bad way the broker can get stuck, and you'll never
> see your messages.
>
> http://issues.apache.org/activemq/browse/AMQ-724
>
Did you use 4.0.1 or the upcoming 4.0.2 (in RC and being voted on
right now)? As the bug mentioned, it's been fixed in 4.0.2.
I googled RPA and all I got was a wiki filled with spam.
Here is a suggestion for people running wikis and trac.
Use captcha.
Better yet: don't. Better to use a Wiki that does other proactive
stuff. Most CAPTCHA implementations wouldn't even remotely pass any
disability testing.
What about quizzing the user on ruby?
For example:
Complete the following expression so that it evaluates to true:
[1,2,____].last == 3
It might be an interesting rubyquiz to _generate_ such questions. There should be enough variety in the questions to prevent bots from solving them. They should also have fairly obvious meaning (like this one) so that you don't have to be a ruby expert to solve them.
···
On 10/29/06, Tim Uckun <timuckun@gmail.com> wrote:
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
On 10/29/06, Tim Uckun <timuckun@gmail.com> wrote:
I googled RPA and all I got was a wiki filled with spam.
Here is a suggestion for people running wikis and trac.
Use captcha.
Better yet: don't. Better to use a Wiki that does other proactive
stuff. Most CAPTCHA implementations wouldn't even remotely pass any
disability testing.
-austin
Yeah ... it took me five tries to get by a captcha yesterday. The
background was so intense that I couldn't read some of the letters, and
the "generate new image" button didn't work! I had to back out and
reload the "register new account" page.
On Behalf Of Mauricio Fernandez:
# I have restored most of the wiki
# (http://rpa-base.rubyforge.org/) and disabled
# modifications for the time being.
rpa's manifesto (and the initial program) is impressive. very useful for enterprise/production need especially the strict documentation and testing (package wont install if test fails). It would also be useful if there is a performance test included. If package fails performance test, it would not install, too.
i really hope rpa would continue. Can't rpa read gems, and thereby rpa-fied it?
On Oct 30, 2006, at 12:08 PM, Joel VanderWerf wrote:
Austin Ziegler wrote:
On 10/29/06, Tim Uckun <timuckun@gmail.com> wrote:
I googled RPA and all I got was a wiki filled with spam.
Here is a suggestion for people running wikis and trac.
Use captcha.
Better yet: don't. Better to use a Wiki that does other proactive
stuff. Most CAPTCHA implementations wouldn't even remotely pass any
disability testing.
What about quizzing the user on ruby?
For example:
Complete the following expression so that it evaluates to true:
[1,2,____].last == 3
It might be an interesting rubyquiz to _generate_ such questions.
On Oct 30, 2006, at 12:08 PM, Joel VanderWerf wrote:
Austin Ziegler wrote:
On 10/29/06, Tim Uckun <timuckun@gmail.com> wrote:
I googled RPA and all I got was a wiki filled with spam.
Here is a suggestion for people running wikis and trac.
Use captcha.
Better yet: don't. Better to use a Wiki that does other proactive
stuff. Most CAPTCHA implementations wouldn't even remotely pass any
disability testing.
What about quizzing the user on ruby?
For example:
Complete the following expression so that it evaluates to true:
[1,2,____].last == 3
It might be an interesting rubyquiz to _generate_ such questions.