Forum: Ruby where to begin?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Oin M. (Guest)
on 2007-01-02 14:07
(Received via mailing list)
Hello!

I would like to start working on a real project. Start "seeing some
action".
I've been reading through ruby books for half a year now, but i haven't
yet
started to make real programs. What I would like to do is help an
opensource
project somewhere, but i don't really know how or who would need this
help
and what skills would that require. There are a lot of questions. When
am I
good enough to enroll in such a project? What do I do? Where do I look?

I tried searching for a project on rubyforge, but I only found 3
requests for
a ruby developer and they all looked too complicated. I got put off when
seeing so many lines of code. How exactly does a new developer help when
joining a big project that has been going on for a very long time.
Should I
even attempt that?

there are really lots of questions in my mind. I hope someone will point
me in
the right direction.

Thank you!
Timothy H. (Guest)
on 2007-01-02 14:17
(Received via mailing list)
Oin M. wrote:
> a ruby developer and they all looked too complicated. I got put off when
> seeing so many lines of code. How exactly does a new developer help when
> joining a big project that has been going on for a very long time. Should I
> even attempt that?
>
> there are really lots of questions in my mind. I hope someone will point me in
> the right direction.
>
> Thank you!
>
A lot of open source projects need better documentation. A way to start
might be to study a project that interests you and work on their doc. In
the process of doing so you'll probably need to write a lot of example
programs to learn how the code works. It's quite possible that you'll
find bugs for which you could try to write the fix. If you read and
write a (human) language other than the one used for the project's
current doc, you could offer to translate it.
spooq (Guest)
on 2007-01-02 14:23
(Received via mailing list)
On 1/2/07, Oin M. <removed_email_address@domain.invalid> wrote:
> When am I good enough to enroll in such a project?

When a team accepts your code, then you are good enough. Most projects
will take any useful contributions, you don't have to be "enrolled".
Keep submitting code, and you'll probably get write access to the
repository sooner or later.

> What do I do? Where do I look?

You can always start your own project. Sourceforge is full of ideas
without code, although you shouldn't feel bound to listen to someone
just because they put up a project page. If they haven't done anything
with their idea, implement it yourself and reap the eternal glory. ;)

> How exactly does a new developer help when
> joining a big project that has been going on for a very long time. Should I
> even attempt that?

This is indeed a difficult question. Generally, I move into new
projects by reading source code (and documentation, if it exists),
asking questions and taking on some small bugfixing assignments.
Anything that helps you get into the groove of the codebase is good.
Even just running the software and submitting bug reports should be
appreciated by the team. If you find a bug, try to fix it yourself.

Good luck!
Jason B. (Guest)
on 2007-01-02 20:35
Timothy H. wrote:
> A lot of open source projects need better documentation. A way to start
> might be to study a project that interests you and work on their doc. In
> the process of doing so you'll probably need to write a lot of example
> programs to learn how the code works. It's quite possible that you'll
> find bugs for which you could try to write the fix. If you read and
> write a (human) language other than the one used for the project's
> current doc, you could offer to translate it.

I am in the same boat as Oin M. although I am pretty sure my code is
not yet sufficient to contribute to anything.

I am really interested in your suggestion of working on projects' rdocs
and I am native English-speaker but I live in Colombia and could easily
translate any documentation into Spanish.

Could you suggest a project where I could get started or point me in the
direction of where I could find such projects?

Many thanks!!!
Tim X (Guest)
on 2007-01-03 08:35
(Received via mailing list)
Oin M. <removed_email_address@domain.invalid> writes:

> I've been reading through ruby books for half a year now, but i haven't yet=
> or=20
> a ruby developer and they all looked too complicated. I got put off when=20
> seeing so many lines of code. How exactly does a new developer help when=20
> joining a big project that has been going on for a very long time. Should I=
> =20
> even attempt that?
>
> there are really lots of questions in my mind. I hope someone will point me=
>  in=20
> the right direction.
>

It usually takes a bit of time to get across any project you join which
has
been running for a while. Don't look at all the lines of code to start
with as
you will get  overwhelmed. My recommendations are

1. First, find a project you are really interested in. don't worry about
the
complexity or size. It is far more important to get involved in
something you
have an interest in if you don't want to lose momentum too quickly.

2. Start by offering to provide testing support. All projects need
testers. The
advantage of starting off here is that you will get to understand the
project,
the objectives and how the application works. This high level conceptual
understanding is critical for getting to understand the lower level
aspects.
Most projects also require people to write documentation. While this is
often a
bit boring and doesn't have the cred of being a code contributor, its
important
and a good way to verify you have the concepts and proper understanding
of the
app. Projects will often succeed or fail based on the quality and
relevance of
the documentation.

3. As you get to understand the app through testing, start doing some
simple
basic debugging of problems you find. Initially, just start with clear
documentation of the problem, providing test cases which can reproduce
the
issue and then start providing additional infora\mation and tracking
down the
specific module/file and then the code. Apart from allowing you to get
more
familiar with the application, you will also get familiar with the
coding
conventions, learn additional techniques and slowly develop your own
code
knowledge.

4. Once you are comfortable with the app, its code etc, select some
problems
from the bug tracking system for the project and try to solve them.
Provide
your solutions to others in the team for their comment and suggestions.
don't
be too thin skinned - some people tend to be very blunt when providing
criticism of code. Put your ego aside as much as possible and try to
appreciate
what the basis of their criticism is. Sometimes, you may just disagree
with
their analysis, but try to understand where they are coming from and
don't be
too defensive.

5. Finally, be patient. Most interesting applications/projects are
fairly
complex and it will take a while before you really understand many of
the
finer points. Don't bee to embarrassed to ask for criticism and provide
your
work for others to review. Above all, get involved in something you find
interesting rather than just something you think will be easy and be
prepared
to take a while before you feel as though you are providing valuable
contributions.

HTH

Tim
Mat S. (Guest)
on 2007-01-03 16:18
(Received via mailing list)
On Jan 3, 2007, at 1:35 AM, Tim X wrote:
> have an interest in if you don't want to lose momentum too quickly.
> this is often a
> basic debugging of problems you find. Initially, just start with clear
> knowledge.
> what the basis of their criticism is. Sometimes, you may just
> provide your
>
> --
> tcross (at) rapttech dot com dot au

And a hearty +1 to that!  Nice work, Tim.  That's probably one of the
best primers I've seen so far.  You should blog that, assuming you
haven't already.  Maybe see how it fares on digg :)
-Mat
Tim X (Guest)
on 2007-01-04 06:11
(Received via mailing list)
Mat S. <removed_email_address@domain.invalid> writes:

>> something you
>> Most projects also require people to write documentation. While
>> some simple
>> own code
>> to appreciate
>> finer points. Don't bee to embarrassed to ask for criticism and
>> Tim
>>
>> --
>> tcross (at) rapttech dot com dot au
>
> And a hearty +1 to that!  Nice work, Tim.  That's probably one of the
> best primers I've seen so far.  You should blog that, assuming you
> haven't already.  Maybe see how it fares on digg :)
> -Mat
>
>
Thanks. However, I'm embarrassed to admit I still don't have a blog!
Just one
of those "to do" items that doesn't seem to rise to the top.

Tim
This topic is locked and can not be replied to.