We have looked at using code coverage tools in the past, and while
they're useful they don't help us ensure we're behaving correctly. We
mostly have to run and re-run tests and applications to find all the
holes. We will try to look at JIRA though...and I think it's been
mentioned in the past.
The
Do you have a list of existing bugs, so I don't send you things that
have already been logged? Have you considered using JIRA
(http://www.atlassian.com/software/jira/)? You can get a free license
for Open Source projects. I use it here at work, and it's really a
phenomenal application.
-Ben
On
That is the goal, to be able to run Rails (and all other Ruby
applications) inside JRuby...and by extension on the JVM. There's no
reason Rails couldn't run out-of-the-box on JRuby in a normal
Rails-style deployment, but given that a typical Rails deployment is
CGI-based, it would not make much sen
On Thu, 16 Feb 2006, John Wells defenestrated me:
> Charles O Nutter said:
> > The "March" timeframe is perhaps from previous presentations? We are
> > still targeting March to get Rails working, but exactly what it will
> > look like is not set in stone. We are looking at a scenario similar to
> >
Charles O Nutter said:
> The "March" timeframe is perhaps from previous presentations? We are
> still targeting March to get Rails working, but exactly what it will
> look like is not set in stone. We are looking at a scenario similar to
> what you describe, with an app server acting to send reques
The "March" timeframe is perhaps from previous presentations? We are
still targeting March to get Rails working, but exactly what it will
look like is not set in stone. We are looking at a scenario similar to
what you describe, with an app server acting to send requests into
Rails as Apache would n
