Rails plugins and libraries / Article metadata

From WhyNotWiki

Jump to: navigation, search
Article Metadata: Internal organization

This list is organized along the "core/internals"-"presentation/unimportant" continuum, referencing the Model-View-Controller paradigm where applicable. Things are organized roughly according to this order:

A plugin may only be listed in one primary category. Of course, not everything fits neatly into this organization and some things could fit equally well in two categories, but we'll see how it works...

  • Some entries have cross-cutting (multiple) concerns, in which case it's okay to list them. But you still have to choose a primary organization.
  • If you can't decide which category should be the primary one, here are some (order of precedence) guidelines which probably won't be helpful at all.
    • [Testing (category)] comes before MVC categorization. So if something is a test for caching, then it should go under Testing / Caching before Caching / Testing...
    • [Ruby-level (category)] comes before topical categorization. So Ruby-level / Dates before Top-level / Dates...
    • Performance monitoring/improvements and Permissions/Security currently take precedence over more specific concerns, since these are fairly cross-cutting in their MVC concerns anyway.
    • It being a Development tool (rather than a production tool) trumps other factors. "Development / Database" over "Database / Development".
    • Web services property (Google Maps API, etc.) trumps MVC.

†Most of this organization is inherited from/parallel to the organization of Rails.

Article Metadata: Scope and purpose

Comparable in scope to http://rubyfurnace.com/ . Intended, of course, to be the best directory of plugins available.

How is it different/better than all the other many directories out there?

  • The problem with most directories is that their default "list" view doesn't show enough detail, making comparison a slow and click-ful process. I think a lot of the information from the "detail" view ought to be listed in the list view (customizable, of course), allowing easy side-by-side comparison, and quick skimming of what's available without a lot of clicking...
    • There will not bee too much information on a page because you will browse by category. (No sense comparing apples with pickles!)
  • Designed to allow rapid evaluation and comparison.
    • There are many criteria that people use when deciding whether or not to use a particular plugin / which from among a set of alternatives to use. The editors will highlight those things that they think are most useful in deciding whether or not to use a particular plugin. Both the good and the ugly.
      • features — does it solve the problem(s) you need it to solve?
      • code prettiness (mostly considering the code you have to write to make use of it; but also considering their code, because if it's written poorly, there is a greater chance of bugs, poor maintenance, ...) (=> relevant code samples are included when helpful.)
      • performance considerations
      • number of dependencies
  • †Hand-edited (by humans).
    • Relevant/Useful: Descriptions only contain relevant information. Information that will help you to decide at a glance if you are interested in learning more about / using that plugin. If that means going over to their blog and pulling a juicy example, then that's what I'll do to make it relevant.
    • Quality editing. No broken markup (<).
    • Selective. Only good (human-screened) plugins make it in.
  • †Categorized hierarchically: Makes it easy to browse to a category that interests you currently and just look at plugins in that category
  • †More categories/tags/metadata than most of the competition
  • †See more on one page (if you want -- well, currently you have no choice...but you will) -- multiple projects so it's easy to compare them -- don't have to click a bunch of times / open a bunch of windows to get the details and compare
    • Eventually you will be able to see a concise list and click "Details" to Ajax-load the details
  • Doesn't aim to be comprehensive, so the list is not cluttered with useless plugins. (Or if it ever does become comprehensive, then maybe most of them will be filtered out by default...)
  • Links to related things in other "areas" -- for example, "Testing" category will let you quickly jump over to see all Ruby (not Rails) testing libraries available. (Browse along different dimensions, not limiting you to stay only within Rails plugins.)
  • †Personalizable: can add your own notes and comments and examples; the others only let you keep your own favorites list ... if that.
  • †Pulls from multiple sources -- combines the best information, descriptions, examples, metadata from each
    • No other directory has links to both Agilewebdevelopment.com and Rubyfurnace.com (not that that's useful, but hey...)
    • So at the least it will contain all the data that the others do, but it will try to add more useful data to the mix
    • Cull the best comments/examples from blogs
  • Human-readable first, machine-readable second.
  • †Structured/machine-readable.
    • Encourage people to use it as a web service, etc.
    • I would like the controllers to be able to export XML/etc. to user agents that know how to use it

† Traits inherited from parent topic, "Software projects database"

Article Metadata: To do
  • Tableize: Move data into software_projects table and pull from there.
    • Use ActiveScaffold to list? Does it also work for detail lists like this is trying to be?
    • When doing an ActiveScaffold list within a certain category/section, have all new inserts scoped so that they get added to that category automatically.
  • Set it up to scrape [Repository URL, Homepage URL, Authors, License, Tags, install command] from rubyfurnace.com and store those values in software_projects table if !exist?() already.
Article Metadata: Fields

Fields:

  • †Repository URL
    • "install command" virtual attribute can be inferred from this. Can be used by a command line plugin browser/installer tool
  • †Homepage URL
    • Problem: People's "Homepage URL" for a plugin is often a blog post... wich may be very informative, but it may become out of date (?) because it (unlike a wiki article) probably won't be updated with new information (instead, they'll probably write a new post). Better to link to their blog's category for that plugin? Or what?
  • †Authors
  • †License
  • †Tags (using acts_as_taggable?)
  • †Rating (using acts_as_ratable?)
  • gem URL / is it available as a gem?

† Columns inherited from parent topic, "Software projects database"


Retrieved from "http://whynotwiki.com/Rails_plugins_and_libraries_/_Article_metadata"
Personal tools