< :the previous in number
^ :the list in numerical order
> :the next in number
P :the previous (in thread)
N :the next (in thread)
|<:the top of this thread
>|:the next thread
^ :the parent (reply-to)
_:the child (an article replying to this)
>:the elder article having the same parent
<:the youger article having the same parent
---:split window and show thread lists
| :split window (vertically) and show thread lists
~ :close the thread frame
.:the index
..:the index of indices
Jim Freeze wrote:
>>
> I'm curious if you are using a coding standard and if you
> use a test-first coding methodology with UnitTest.
>
> Has it been easier or harder to use ruby in a multiple
> programmer environment than C or C++?
>
> Just curious.
>
The business objects have all been implemented test-first, but the interface
objects have only been tested by a human at a browser. Working on this.
We use Lapidary, which is now Test::Unit to write all of the tests. We use
CVS for version control, and this has been much the same process as with
any language. It hasn't been at all difficult to use in a multi-programmer
environment. On the contrary, it has been very easy to split and
coordinate tasks between programmers along class, module, and tier lines.
We start with a UML diagram which is law, implement tests for the objects,
and develop to those tests.
I should mention that I have never worked on a multi-programmer C/C++
program, having only written C programs alone. Our project was originally
written on Windows for Visual Foxpro, and it is definitely easier for
multiple programmers to work on Ruby in a Linux environment. Compared to
large projects I have worked on in Perl, with many developers and lots of
classes, I definitely find the Ruby easier to work with, especially since
programmers don't tend to find as many different ways to write a Ruby class
as a Perl programmer might. Compared to Python I guess I'd say I like Ruby
slightly better, because the DBI module is easy for people to understand
and the form of a Ruby program is easy for Perl and Java programmers to
pick up.
At the time we started the project, we weren't aware of any local Ruby
programmers, so hired Perl, Java, FoxPro, and C++ programmers instead.
It's all the same to them. Now I know there are several Ruby programmers
in Austin and hopefully some day we'll have the budget to work with them.