Code Resue for Ruby Gems, Plugins, Git

We see several broad areas where we want code reuse.

	Public	Protected	Private
Origin	RubyForge, GitHub, RailApp, etc.	Org Internal: shared by projects	Org Internal: specific to one project
Examples	Rails Bcrypt Hoptoad	Org rails base app Org business rules Org stylesheets	Rails app "Foo" Gems for "Foo" Layouts for "Foo"

Gems	Install on the system using gem install --test Add gem requirement to app config.rb with a version and source When you clone or deploy an app, run rake:gems Do not vendor gems
Plugins	Is there is a gem version? Yes: use it because gems are better. No: install the plugin using script/install plugin
Files	Can you refactor it to be a gem or plugin? Yes: refactor No: create a git project, upload it to the org's github shared folder.

Recommendations

Rake gems

The app will define its gems in config.rb, then we use rake gems.

Rake plugins

The org's base app will not come with pre-installed plugins.
Instead, it should have a rake task (TBD) that installs plugins,
possibly by prompting the developer yes/no for each plugin.
e.g. "Do you want to use Hoptoad to report your exceptions?"

Rake submodules

We want a rake task that creates git submodules for shared files,
possibly by prompting the developer yes/no for each submodule,
e.g. "Do you want to use Dave's gray CSS layout?"

Naming Convention

Create a "shared" directory for models, views, controllers, etc.
e.g. models/shared/foo/, views/shared/goo/, controllers/shared/hoo

Modular

Make your shared code as small and as specific as possible,
because this is easier to test, deploy, document, and update.

Bundling

We may want/need to create aggregator gems and git models
that bundle some of our small gems with related functionality.

Gem Server

We want a gem server where we can share org-protected gems,
ideally with password protection and also external availability.

Upstreaming

When we create fixes to public gems and plugins,
we want to submit the fixes upstream to the authors
rather than managing our our forks/clones/copies,
e.g. we want annotate_models to omit line numbers.

Open Source

We want to create ways for the org to contribute to open source.
A good first candidate is improvements to existing public gems.

---

What's Next?

• Index Of Articles: Web Design & Development

blog comments powered by Disqus