[BioRuby] A question for BioRuby newbies
Michael Barton
mail at michaelbarton.me.uk
Wed Feb 8 20:52:57 UTC 2012
I think this is a very good idea. More public engagement
would be a boon to the BioRuby project. I would be happy to
help new developers work on my Scaffolder gem. Here are two
additional suggestions from me for increasing BioRuby
participation.
First suggestion:
I think the bioruby home page could be made simpler. A very
rough estimate shows 80 links on the front page:
curl http://bioruby.open-bio.org/ | tidy -i -q | grep href | wc
-> 80 links
Compare this with the Rails and Sinatra homepages:
curl http://rubyonrails.org/ | tidy -i -q | grep href | wc
-> 47 links
curl http://www.sinatrarb.com/ | tidy -i -q | grep href | wc
-> 20 links
I think making the homepage simpler would be very
beneficial. For instance I think the two most important
links (Tutorial and Sample codes) pages should be given much
greater prominence. These are the two pages which most
beginners will want to get started with. Compare with the
Sinatra page which has only six links on the front page
pointing to the most significant parts of the project.
I think the Tutorial and Sample codes pages could do with
some love also. These pages do not match the visual layout
of the bioruby home page, one is in a separate domain while
the other is a wiki page. I think these pages deserve
attention to make them simpler and more accessible. A common
CSS theme also provides a unified front to the BioRuby
project.
Compare with the Sinatra intro and documentation pages:
* http://www.sinatrarb.com/intro
* http://www.sinatrarb.com/documentation
My opinion is that the BioRuby website should head in this
direction. I am not a web designer but I am happy to
contribute effort to writing web copy and BioRuby recipes. I
also think that bioruby should also have its own web address
too.
Second Suggestion:
I think as BioRuby becomes more and more popular the code
base will continue to increase in size. I think this will
become a disadvantage as a larger code base is harder to
navigate, harder to maintain, and more intimidating to make
contributions to.
Pjotr has addressed this with the BioGems project but I
think we should follow the natural progression and consider
splitting the Bio gem into smaller self-contained gems. I
think this is already starting to happen with the
replacement gff3 and 'faster' fasta gems.
I think smaller gems would be easier to maintain and allow
different development cycles. I think it also easier to
create a gem for a new idea rather than find a place for it
in a large pre-existing code base. Finally this would follow
the smaller 'does just one thing' gem development philosophy
in Ruby.
Michael Barton
On Wed, Feb 08, 2012 at 07:48:17PM +0100, Pjotr Prins wrote:
> Hi All,
>
> This mailing list counts 180 subscribed readers.
> Which is impressive. Also since the introduction of
> http://biogems.info/ the number of BioRuby downloads has
> increased rapidly.
>
> You may also have noticed Ruby, in general, is making
> its mark in bioinformatics. More and more people are
> programming in Ruby, which I think rather delightful.
> And Biogems.info is proving to be cutting edge, and
> accelerating development.
>
> So here is a question to people who read the mailing list,
> but do not necessarily participate. What is needed to pull
> you in?
>
> At this point I have two ideas to increase participation.
>
> (1) First a race. I would like all readers to vote a few
> times a year on the most beautiful Biogem source code.
> We'll put up a few projects to choose from, and the winner
> will be highlighted on http://biogems.info/. Ruby is about
> beauty, and we are seeing some of that in the biogems.
>
> The other idea I got at FOSDEM this year from a convincing
> talk by Brian Ostergard, titled 'You are doing it all
> wrong'
>
> http://fosdem.org/2012/schedule/event/really_grow_commun
> ity
>
> where he made a strong case to address inexperienced
> developers. And you know what, I believe he is right. So
>
> (2) We will look for ways to get inexperienced developers
> involved. One way is to define uncomplicated and
> moderately complicated tasks, feature requests and bug
> fixes.
>
> We are going to list these 'jobs' on http://biogems.info/.
> If anyone picks up a task he/she will get very *strong*
> support from the plugin owner, as well as the Biogem
> maintainers. You, the programmer, will get all the credit
> for the work.
>
> How does this sound? Does this appeal to you? Anyone of
> the less experienced, or even experienced, wants to voice
> his or her opinion? We may even turn some work into a
> Google Summer of Code project proposal.
>
> Pj. _______________________________________________
> BioRuby Project - http://www.bioruby.org/
> BioRuby mailing list BioRuby at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioruby
More information about the BioRuby
mailing list