I think this might be a nice companion piece to James' gem-this talk,
maybe you could collaborate? As I see it Gem-this is about letting
you not follow the proscribed rules about code layout and organisation
that something like Hoe or even rails dictates, but we still need some
structure and order to our hacking so that we can be good ruby
citizens. There's probably some follow-on from Sean's talk last year
about how best to not pollute the default namespace as well.
Are you up for giving this a go Chris?
2009/11/12 Kalvir Sandhu <k...@kalv.co.uk>:
> I would be interesting in hearing a bit about this too. Having recently
> built some Ruby applications, things like how best to use rubygems on it's
> own, handling dependencies (Versions) would be nice to know. Not sure what
> else could be in a talk of this kind - it might be a little short.
> Til now I have just modelled things based on existing frameworks or gems but
> I haven't found any Ruby Applications to learn from.
> Kalv
> On 12 Nov 2009, at 00:19, Chris Roos wrote:
> I'm not sure whether this is a big enough subject to warrant a talk
> but I'm interested in how I should be organising non-rails projects.
> * Should I require rubygems or not? I've read that I shouldn't but I
> think I need to see concrete examples of why it's such a bad idea.
> * Should I have one main file that requires everything else or should
> individual files be responsible for requiring what they need?
> * Should I require files relative to each other (the
> File.join(File.dirname(__FILE__)... pattern)? I seem to remember the
> generated rails tests no longer do this but I don't remember seeing
> concrete reasons for the change.
> * Other stuff that I can't think of.
> Chris