Forum: Ruby DHH vs. WHY style

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.
Trans (Guest)
on 2007-04-25 22:17
(Received via mailing list)
Like to know others general opinions on having a comprehensive library
vs. independent libraries.

In my quest to make Facets' functionality available in some smaller
parts, I am left with hard choice. I think of it as the DHH vs. WHY
style question, b/c these two well known developers most clearly
reflect the approaches in their work. For DHH (ie. Rails) we have a
number of libs with closely labeled packages: ActionPack,
ActionMailer, ActiveSupport, ActiveRecord, etc. While _why's libs all
have highly independent packaging with clever names: Markaby, Hpricot,
Syck, etc. Now, I realize that different circumstances have certainly
led to this, eg. Rails is meant as a single comprehensive web-
framework, while Why's packages are more unique and reflect his
exceptional creatively, but either could have taken the other approach
if they so wished. And in my case (and surely some other large
projects as well), the distinction is not as straight forward.

So my question is, which is preferable? What criteria should one base
this decision on?

To clarify here is my specific scenario. I've narrowed it down, more-
or-less, to these Whyish vs. DHHish possibilities:

  Aces        Facets/CORE
  Jacks       Facets/BASE
  Tapestry    Facets/AOP
  Comrade     Facets/CLI
  Fileside    Facets/FS
  Annote      Facets/ANN

A couple of the names I'm not 100% sure about yet, but you get the
idea. I've been thinking about this a long time and haven't been able
to decide what direction to take for future development. It's most
significant impact, I suppose, is to the require namespaces ('facets/
aop/' vs. 'tapestry/' for example). The only other solid difference I
have found between them is that some libs don't mesh well with the DHH
style so those need to be completely separate anyway (for instance, my
modified redistribution of HTTPAccess2).

Thanks for any insights,
T.
Phillip G. (Guest)
on 2007-04-25 23:05
(Received via mailing list)
Trans wrote:

> To clarify here is my specific scenario. I've narrowed it down, more-
> or-less, to these Whyish vs. DHHish possibilities:
>
>   Aces        Facets/CORE
>   Jacks       Facets/BASE
>   Tapestry    Facets/AOP
>   Comrade     Facets/CLI
>   Fileside    Facets/FS
>   Annote      Facets/ANN

FacetsCore
FacetsBase
FacetsAOP #(if that is an acronym)
FactesFileside
FacetsAnnote

or turn that around:
CoreFacets
BaseFacets
AOPFacets
FilesideFacets
AnnotateFacets

This seems to be the most pronounceable to me, and leaves room for
others. You should go with the Rails way, as you have a common framework
already (facets) in use, and keeping the name facets makes transition
easier for the existing user base.

My 0.02EUR

--
Phillip "CynicalRyan" Gawlowski
http://cynicalryan.110mb.com/
http://clothred.rubyforge.org

Rule of Open-Source Programming #5:

A project is never finished.
MenTaLguY (Guest)
on 2007-04-26 00:11
(Received via mailing list)
On Thu, 26 Apr 2007 03:16:52 +0900, Trans <removed_email_address@domain.invalid> 
wrote:
> So my question is, which is preferable? What criteria should one base
> this decision on?

For me, the main criteria when deciding whether to give packages related
names is the level of interdependence between them.  If they're mostly
all usable in isolation, there's no reason to give them related names.

-mental
Nicholas Van W. (Guest)
on 2007-04-26 01:14
(Received via mailing list)
What are people "buying" so to speak?

Do I want a "Facets", or an AOP framework? If I want AOP and CLI, do I
want
them bundled, or separate? What do I get for them being together? What
does
Facets add to them?

Also, consider branding/marketing considerations.  Publicity requires
naming
that enables discussion and clarity of what you are discussing. What is
Facets? What kind of publicity (market discussion and understanding)
does it
generate? What is Facets/CLI? Can a name like that generate publicity?

Comrade, a CLI framework for building command-line tools, is an
interesting
discussion. Now what does Facets add to the discussion?

Facets/CLI ties CLI to a meta-brand, but what does the meta-brand mean?
Does
it strengthen the position of CLI (interoperability?, a common
extensions
meta-programming model? ), or weaken it (a partial CLI, rather then a
full-fledged CLI framework).

ActiveRecord actually has a brand separate from Rails because of the
name,
and the high-level of publicity regarding it's model for ORM.  The
separate
name helped- people talked at length about ActiveRecord, separate of
considerations of Rails. This helped strengthen the Rails brand
(full-stack
+  ActiveRecord= fast development).

Then there are the use-cases regarding library usage. Do the components
work
together? Is this valuable? Is this their purpose? Are the components
supposed to be best-in-class, or convenience items by virtue of
bundling.

I don't know much about Facets, but my question is what value Facets
adds to
CLI and AOP in the users mind.

On comprehensive libraries in general, what makes it worthwhile? What
kind
of thematic or practical bundling adds value?

To me, comparing Rails to Why's packages seems to be the wrong approach.
You
want to look across broader vistas for similar packaging of disparate
features. What Unix equivalents are there, and what drove the bundling?

Cheers,
Nick
Tomas P.'s Mailing L. (Guest)
on 2007-04-26 01:40
(Received via mailing list)
On Thu, 26 Apr 2007, Trans wrote:

> Syck, etc. Now, I realize that different circumstances have certainly
> or-less, to these Whyish vs. DHHish possibilities:
>
>  Aces        Facets/CORE
>  Jacks       Facets/BASE
>  Tapestry    Facets/AOP
>  Comrade     Facets/CLI
>  Fileside    Facets/FS
>  Annote      Facets/ANN

Well, the names first column are library names that don't have any
imediate meaning to me and moreover overlap with other libraries' names
(Aces (distributed programming c-lib), Jacks (sound system), Tapestry
(java-lib?)), so they might be funny and clever but not helpful.

The second column pretty clearly says what a library is about.

So I'd prefer use/helpful to funny/clever.
*t

--
unknown (Guest)
on 2007-04-26 02:30
(Received via mailing list)
On Thu, 26 Apr 2007, Trans wrote:

> To clarify here is my specific scenario. I've narrowed it down, more-
> or-less, to these Whyish vs. DHHish possibilities:
>
>  Aces        Facets/CORE
>  Jacks       Facets/BASE
>  Tapestry    Facets/AOP
>  Comrade     Facets/CLI
>  Fileside    Facets/FS
>  Annote      Facets/ANN

For Facets, something out of the second column.  If I see a discussion
about Jacks, I may not know what in the heck it is, but if I see
Facets/BASE, I'll have some useful information.


Kirk H.
James B. (Guest)
on 2007-04-26 02:48
(Received via mailing list)
Nicholas Van W. wrote:
> does it
> generate? What is Facets/CLI? Can a name like that generate publicity?

WWSGD?

(What would Seth Godin do?)





--
James B.

"The use of anthropomorphic terminology when dealing with
computing systems is a symptom of professional immaturity."
  - Edsger W. Dijkstra
Ari B. (Guest)
on 2007-04-26 03:21
(Received via mailing list)
On Apr 25, 2007, at 6:47 PM, James B. wrote:

>> What is
>> Facets? What kind of publicity (market discussion and
>> understanding) does it
>> generate? What is Facets/CLI? Can a name like that generate
>> publicity?
>
> WWSGD?
>
> (What would Seth Godin do?)

EWHWDO

(Exactly What He Would Do Otherwise)

Don't pick a weird name like Amerthrall (I just made that up). A good
bet is always something simple.  For instance, CitiBank doesn't
really generate conversations like OOTS generates laughs, but it
sticks with people and is easy to remember.

JMT
~ Ari
English is like a pseudo-random number generator - there are a
bajillion rules to it, but nobody cares.
Jack C. (Guest)
on 2007-04-26 03:42
(Received via mailing list)
Tomas P.'s Mailing L. wrote:
>>  Tapestry    Facets/AOP
>
> So I'd prefer use/helpful to funny/clever.
> *t
+1.
Sammy L. (Guest)
on 2007-04-26 15:31
(Received via mailing list)
Tomas P.'s Mailing L. wrote, On 4/25/2007 4:39 PM:
>> ActionMailer, ActiveSupport, ActiveRecord, etc. While _why's libs all
>>
> Well, the names first column are library names that don't have any
> imediate meaning to me and moreover overlap with other libraries'
> names (Aces (distributed programming c-lib), Jacks (sound system),
> Tapestry (java-lib?)), so they might be funny and clever but not helpful.
>
> The second column pretty clearly says what a library is about.
>
> So I'd prefer use/helpful to funny/clever.

+1
Nicholas Van W. (Guest)
on 2007-04-26 17:11
(Received via mailing list)
On 4/25/07, James B. <removed_email_address@domain.invalid> wrote:
> > Also, consider branding/marketing considerations.  Publicity requires
>
>
There you go! Trans- it doesn't matter, just make sure you have a PURPLE
COW!

Or go more old school-  WWRATD? (What would Ries and Trout do)

Trans- it doesn't matter, just make sure you invent or segment a
category
and own a word in the customers mind! It's all about positioning-
Differentiate or die!

Or WWYD (what would Yoda do)?
The words you chose, important they will become. Power, words have.

Cheers,
Nick
Bob S. (Guest)
on 2007-04-26 17:12
(Received via mailing list)
On 4/25/07, Trans <removed_email_address@domain.invalid> wrote:
> To clarify here is my specific scenario. I've narrowed it down, more-
> or-less, to these Whyish vs. DHHish possibilities:
>
>   Aces        Facets/CORE
>   Jacks       Facets/BASE
>   Tapestry    Facets/AOP
>   Comrade     Facets/CLI
>   Fileside    Facets/FS
>   Annote      Facets/ANN

After thinking about this for about 3 seconds, I like the whimsical
names. _why is cool.
James G. (Guest)
on 2007-04-26 17:27
(Received via mailing list)
On Apr 26, 2007, at 8:12 AM, Bob S. wrote:

>
> After thinking about this for about 3 seconds, I like the whimsical
> names. _why is cool.

It has been interesting hearing everyone say that the right side is
so much more helpful.  I have heard Facets is a collection of
extensions and I'll assume CORE means extensions to Ruby's core, so
maybe I get the first one.  The second one means nothing to me though.

I also don't think whimsical names have to be unhelpful.  When I
ported File::ReadBackwards from Perl, I named my version Elif.  I
guess you have to "get that" before it helps, but I had to know what
Facets was to even make guesses about the more helpful names.  Seems
pretty comparable to me.

So, I guess I'm a rebel:  I like cool names.

James Edward G. II
Daniel S. (Guest)
on 2007-04-26 17:36
(Received via mailing list)
On Thu, 2007-04-26 at 06:39 +0900, Tomas P.'s Mailing L. wrote:
> > ActionMailer, ActiveSupport, ActiveRecord, etc. While _why's libs all
> >
> Well, the names first column are library names that don't have any
> imediate meaning to me and moreover overlap with other libraries' names
> (Aces (distributed programming c-lib), Jacks (sound system), Tapestry
> (java-lib?)), so they might be funny and clever but not helpful.
>
> The second column pretty clearly says what a library is about.
>
> So I'd prefer use/helpful to funny/clever.
> *t

-1. I'd prefer the distinguished libraries to have their own brands, so
that they can be more easily discussed in isolation. Standard libraries,
on the other hand, ought to have descriptive names.


Cheers,
Daniel
Daniel S. (Guest)
on 2007-04-26 17:37
(Received via mailing list)
On Thu, 2007-04-26 at 22:12 +0900, Bob S. wrote:
> _why is cool.

That goes without saying.
James B. (Guest)
on 2007-04-26 19:18
(Received via mailing list)
James Edward G. II wrote:

> I also don't think whimsical names have to be unhelpful.  When I ported
> File::ReadBackwards from Perl, I named my version Elif.  I guess you
> have to "get that" before it helps, but I had to know what Facets was to
> even make guesses about the more helpful names.  Seems pretty comparable
> to me.
>
> So, I guess I'm a rebel:  I like cool names.

I stand with you!  Raise the black flag!

My main concern with purely descriptive names are that they may not pass
the Google test.  That is, if someone mentions it in a post and I want
to learn more, a reasonable search (e.g., ruby+code-name on Google)
should bring it up in the top 10.

I'm not advocating the use of stereotypical Web 2.0 -style names, but
they need not be dry and lifeless.


--
James B.

"In physics the truth is rarely perfectly clear, and that is certainly
  universally the case in human affairs. Hence, what is not surrounded
by
  uncertainty cannot be the truth."
  - R. Feynman
Gavin K. (Guest)
on 2007-04-26 19:25
(Received via mailing list)
On Apr 25, 12:16 pm, Trans <removed_email_address@domain.invalid> wrote:
> Like to know others general opinions on having a comprehensive library
> vs. independent libraries.

I'm confused as to what you're asking about - using a common naming
scheme, or having monolithic libraries versus smaller ones?

(The above bit I quoted would make the answer seem clear, but the rest
of the message seems to be about names.)
Jamey C. (Guest)
on 2007-04-26 19:32
(Received via mailing list)
James B. wrote:
> I stand with you!  Raise the black flag!
>
> My main concern with purely descriptive names are that they may not
> pass the Google test.  That is, if someone mentions it in a post and I
> want to learn more, a reasonable search (e.g., ruby+code-name on
> Google) should bring it up in the top 10.
>
> I'm not advocating the use of stereotypical Web 2.0 -style names, but
> they need not be dry and lifeless.
>
>

+1 for whimsical names.


For the past few years I have participated in a charity volleyball
tournament.  Being that my vertical jump can only be measured by an
electron microscope, my chief contribution to our volleyball team has
been coming up with colorful team names.  So, in the past few years, we
have proudly battled as:

* The Ruptured Spleens

* The Irritable Bowels

and the ever popular

* The Loose Stools


Now, aren't those name much more fun than the more descriptive:

* Six Old Farts Who Can Barely Walk, Much Less Jump And Therefore Should
Not Be Out Here Playing Volleyball


Jamey
Sammy L. (Guest)
on 2007-04-26 20:02
(Received via mailing list)
Jamey C. wrote, On 4/26/2007 10:32 AM:
>
>
> For the past few years I have participated in a charity volleyball
> tournament.  Being that my vertical jump can only be measured by an
> electron microscope, my chief contribution to our volleyball team has
> been coming up with colorful team names.  So, in the past few years,
> we have proudly battled as:
>
> ...
> * The Loose Stools

On the whole, were you all a pretty crappy team?
Jamey C. (Guest)
on 2007-04-26 20:19
(Received via mailing list)
Sammy L. wrote:
>> * The Loose Stools
>
> On the whole, were you all a pretty crappy team?
>

Well, we didn't have a lot of time to practice together, so I guess you
could say we lacked consistency.  ;-)

Jamey
Joel VanderWerf (Guest)
on 2007-04-26 20:37
(Received via mailing list)
Trans wrote:
> Syck, etc. Now, I realize that different circumstances have certainly
> or-less, to these Whyish vs. DHHish possibilities:
> to decide what direction to take for future development. It's most
> significant impact, I suppose, is to the require namespaces ('facets/
> aop/' vs. 'tapestry/' for example). The only other solid difference I
> have found between them is that some libs don't mesh well with the DHH
> style so those need to be completely separate anyway (for instance, my
> modified redistribution of HTTPAccess2).
>
> Thanks for any insights,
> T.
>

What about putting your colorful names inside of generic namespaces?

   aop/tapestry
   cli/comrade
   file/fileside
   text/annote  (?)

This scheme retains distinctiveness, but also communicates the general
purpose of a library: when we see "require 'cli/comrade'" at least we
know it has something to do with command line processing, and not
proletarian uprising. Or, if you really want the facets brand:
"cli/comrade-facet".

But these longer names hardly roll of the tongue...
unknown (Guest)
on 2007-04-26 21:16
(Received via mailing list)
On Fri, 27 Apr 2007, James B. wrote:

> My main concern with purely descriptive names are that they may not pass the
> Google test.  That is, if someone mentions it in a post and I want to learn
> more, a reasonable search (e.g., ruby+code-name on Google) should bring it up
> in the top 10.
>
> I'm not advocating the use of stereotypical Web 2.0 -style names, but they
> need not be dry and lifeless.

The thing here is that he already does have a recognizeable brand with
facets, and 'ruby facets' is the first thing to come up on a google
search.  So, Facets/BASE will certainly do just fine on the Google test,
and it preserves an already well known brand name.


Kirk H.
Chad P. (Guest)
on 2007-04-26 21:44
(Received via mailing list)
On Fri, Apr 27, 2007 at 12:18:30AM +0900, James B. wrote:
> I stand with you!  Raise the black flag!
H.L. Mencken once said: "Every normal man must be tempted, at times, to
spit on his hands, hoist the black flag, and begin slitting throats."  I
just thought I'd share.  It's one of my favorite quotes.


>
> My main concern with purely descriptive names are that they may not pass
> the Google test.  That is, if someone mentions it in a post and I want
> to learn more, a reasonable search (e.g., ruby+code-name on Google)
> should bring it up in the top 10.

Thus, combine the two.  Instead of Facets/File_reverse or Elif, you
might consider using Facets/Elif.  Voila.  Brand recognition, fun, *and*
brand recognition, all rolled up in one convenient package.
Paul B. (Guest)
on 2007-04-26 21:50
(Received via mailing list)
On Thu, Apr 26, 2007 at 10:26:54PM +0900, James Edward G. II wrote:
> I also don't think whimsical names have to be unhelpful.  When I
> ported File::ReadBackwards from Perl, I named my version Elif.  I
> guess you have to "get that" before it helps, but I had to know what
> Facets was to even make guesses about the more helpful names.  Seems
> pretty comparable to me.

Unhelpful names are the prevailing trend, though.  It's true about
software and it's true about many automobile manufacturers.  Some do it
because inventing names is fun, and some do it because less generic
names are better for marketing.  I'm convinced, though, that there is a
group out there of nonzero size that comes up with these names just to
make life difficult for me.

Paul
Clifford H. (Guest)
on 2007-04-27 04:00
(Received via mailing list)
Joel VanderWerf wrote:
> What about putting your colorful names inside of generic namespaces?
>   aop/tapestry
>   cli/comrade
>   file/fileside
>   text/annote  (?)

+1. In fact I have a whole taxonomy of infrastructure
terms I've used, and being able to locate a "body of
work" is much easier if such a taxonomy is used.
Trans (Guest)
on 2007-04-27 16:01
(Received via mailing list)
On Apr 26, 8:00 pm, Clifford H. <removed_email_address@domain.invalid> wrote:
> Joel VanderWerf wrote:
> > What about putting your colorful names inside of generic namespaces?
> >   aop/tapestry
> >   cli/comrade
> >   file/fileside
> >   text/annote  (?)
>
> +1. In fact I have a whole taxonomy of infrastructure
> terms I've used, and being able to locate a "body of
> work" is much easier if such a taxonomy is used.

I like the taxonomy too, but this naming scheme for requires is not
really ideal. These colorful names represent a repository or part of a
repository. In general, a package could just as well have lib files
that fall under variant categories, and I don't think it's a good idea
to spread them out over a number of subdirectories. So it's better as:

   tapestry/aop/..
   comrade/cli/...
   fileside/file/...
   annote/meta/...  (?)

The initial names are simply namespaces that separate these libs from
other repositories/packages. If the libs were part of the standard
library, then the initial namespace could be removed. In fact it would
not be unreasonable to use a domain name for this. For example:

  require 'facets.rubyforge.org/aop/...'

That's really the community friendly way of doing things. Although,
since Rubyforge is by far the most common source of all libs ruby, it
is also reasonable to omit the host name (.rubyforge.org). Indeed,
registering a project with Rubyforge gives one the right to use that
toplevel require space. Unfortunately there's a bit of an unspoken
schism in the community (which I mentioned in an older post) as to
whether it is actually the first use of a gem name that gives one a
right to a toplevel namespace instead. None of this is enforced of
course, but it's basically the unspoken standard. And it clarifies the
difficulty of what I am attempting b/c it means 1) I have to figure
out how to organize and name the redistributable subsections of this
large repository and 2) figure out how that should effect the require
namespaces. Since there is no general consensus on this I am left
figuring out what to call and how to tie together the repository name,
the package names and taxonomy to achieve this.


BTW, I'm really impressed with the responses thus far; lots of great
insights from all of you. Thanks guys!

T.
Clifford H. (Guest)
on 2007-04-28 12:10
(Received via mailing list)
Trans wrote:
>> +1. In fact I have a whole taxonomy of infrastructure
>> terms I've used, and being able to locate a "body of
>> work" is much easier if such a taxonomy is used.

> I like the taxonomy too, but this naming scheme for requires is not
> really ideal.

Agree. The taxonomy idea is for locating a relevant
term, but because it places each term at exactly
one place in the hierarchy, it's not necessary to
use the whole hierarchy in names. So for example,
under my category "network/binding" there is a term
"DNS", which is the network binding for the domain
name system. If Ruby were to have an integrated and
definitive DNS API, it could reasonably be called
module DNS, rather than Network::Binding::DNS.

A definitive extension that adds support for DNS
service requests should be called DNS::Service.
The important point is that the library must (aspire
to) completely cover the conceptual space allocated
by that area of the taxonomy. If it doesn't, then
give it a wacky name under the place of best fit.

So if someone then came along and made a nice library
for doing something special like using DNS Service
requests to locate Windows domain controllers, it
would get called DNS::ColorfulName, and required as
"colorfulname". So the taxonomy exists really only
for the "accepted standard" way of doing things,
and as assistance in locating non-standard things.

I've also used what I call "facet naming". For example,
NT is a category under Operating Systems, and Kerberos
is a category under Security, so when I had a module
that did something with Kerberos, but was limited to
NT, the module got a parenthesized qualification added
to its name: "Security/Kerberos (NT)". The parenthetical
qualification identifies this as being top-level Kerberos
functionality, but pertaining only to NT. In this case
a Ruby module name would be Kerberos::NT, and the require
would be "kerberos/nt". The re-use of a term "NT" that's
defined elsewhere in the taxonomy identifies this as a
facet name, rather than a sub-category.

Using facet naming, every object "belongs to" one area
(Kerberos here) but potentially "pertains to" another
one (NT). This allows full aspect-oriented naming of
cross-cutting concerns.

Anyhow, I don't know whether any of these concepts have
value for the current problem, but I thought that with
your penchant for AOP and the fact that the current
subject is your Facets library, you'd be interested :-).

> ...it clarifies the
> difficulty of what I am attempting b/c it means 1) I have to figure
> out how to organize and name the redistributable subsections of this
> large repository and 2) figure out how that should effect the require
> namespaces.

Can I ask that you clearly identify and perhaps separate
items from Facets that have a strong potential to interact
and break other frameworks? I really like most of Facets,
but sometimes I just can't bear the risk of partly-hidden
strangeness.

Clifford H..
Trans (Guest)
on 2007-04-28 17:42
(Received via mailing list)
On Apr 28, 4:10 am, Clifford H. <removed_email_address@domain.invalid> wrote:

> A definitive extension that adds support for DNS
> "colorfulname". So the taxonomy exists really only
> functionality, but pertaining only to NT. In this case
> a Ruby module name would be Kerberos::NT, and the require
> would be "kerberos/nt". The re-use of a term "NT" that's
> defined elsewhere in the taxonomy identifies this as a
> facet name, rather than a sub-category.
>
> Using facet naming, every object "belongs to" one area
> (Kerberos here) but potentially "pertains to" another
> one (NT). This allows full aspect-oriented naming of
> cross-cutting concerns.

You remind me that I didn't address module namespace in my last post --
further complicating the matter.

> Anyhow, I don't know whether any of these concepts have
> value for the current problem, but I thought that with
> your penchant for AOP and the fact that the current
> subject is your Facets library, you'd be interested :-).

Funny how concerns can overlap even in orthogonal ways ;-)

> strangeness.
Actually, I've already done this very thing. "Facets 2.0" (however I
end up subdividing the parts) will be a much cleaner library. But if
you have a specific concerns in this regard please let me know so I
can make sure they have been addressed.

T.
Peter C. (Guest)
on 2007-04-29 01:37
(Received via mailing list)
On 4/26/07, Ari B. <removed_email_address@domain.invalid> wrote:
>
> Don't pick a weird name like Amerthrall (I just made that up). A good
> bet is always something simple.  For instance, CitiBank doesn't
> really generate conversations like OOTS generates laughs, but it
> sticks with people and is easy to remember.


Unlike, say, Google? The opposing view doesn't seem to have hurt the
popularity of Hpricot, Mongrel, Hoe, or, heck, even "Rails" itself, and
they're some of the biggest Ruby related projects out there ;-)

That said, I must admit I partly agree with you when it comes down to
tools,
rather than brand names. Rails is certainly a brand, and has almost
certainly been intended to be one from very early on. Same for Hpricot
and
Mongrel, I'd say. Some small library with a niche function though..? I'd
say
your advice would be right for that.

Cheers,
Peter C.
http://www.rubyinside.com/
Sammy L. (Guest)
on 2007-04-29 08:01
(Received via mailing list)
Peter C. wrote:
> On 4/26/07, Ari B. <removed_email_address@domain.invalid> wrote:
>>
>> Don't pick a weird name like Amerthrall (I just made that up). A good
>> bet is always something simple.  For instance, CitiBank doesn't
>> really generate conversations like OOTS generates laughs, but it
>> sticks with people and is easy to remember.
>
>
> Unlike, say, Google?
I'm not sure that name came from nowhere....
(http://en.wikipedia.org/wiki/Googol)  Of course, I assume most probably
knew that...

> I'd say
> your advice would be right for that.

I was never sure if this thread was talking about naming
classes/packages or a product.  In my view, you should name products
distinctly, and its quite ok to give them cute names.  But giving
code-related things names that are nonsensical /is/ nonsensical.  It may
seem cute, but its often quite useless.

After reading this one, I'm still no closer to knowing if we are talking
about products or code. =)  But I'm leaning ever closer to knowing I
just don't know.  =)

Sam
Trans (Guest)
on 2007-04-30 17:43
(Received via mailing list)
On Apr 29, 12:00 am, Sammy L. <removed_email_address@domain.invalid> wrote:
> I'm not sure that name came from nowhere....
> > certainly been intended to be one from very early on. Same for Hpricot
>
> After reading this one, I'm still no closer to knowing if we are talking
> about products or code. =)  But I'm leaning ever closer to knowing I
> just don't know.  =)

Well, at heart, we're dealing will about 100 or so libraries (ie.
files). The vast majority of which can stand on there own. I'd have to
be crazy to give each and every one a colorful name, but some of them
do admit of clear relationships, like the libs pertaining to CLI and
AOP. Presently Facets is one monolithic library collection. That's
good for brand recognition around "Facets", but it also seems to hurt
uptake b/c programmers tend to look for more focused solutions.

Per the original query. I could subdivide the libs into taxonomic
categories, eg. cliFacets, aopFacets, and what have you. That would
help, but I worry it would still not be enough to spur this focused
uptake. And I also wonder if it would still stifle development since
they remain part a larger collective.

T.
Sammy L. (Guest)
on 2007-04-30 18:02
(Received via mailing list)
Trans wrote, On 4/30/2007 8:42 AM:
>>> and
>> After reading this one, I'm still no closer to knowing if we are talking
>> about products or code. =)  But I'm leaning ever closer to knowing I
>> just don't know.  =)
>>
>
>

Thanks for the clarification. I have some more comments/questions below.

> Well, at heart, we're dealing will about 100 or so libraries (ie.
> files). The vast majority of which can stand on there own.

What is preventing you from making them stand on their own?

> I'd have to
> be crazy to give each and every one a colorful name, but some of them
> do admit of clear relationships, like the libs pertaining to CLI and
> AOP.

So, now you are looking to group them into more cohesive chunks?

> Presently Facets is one monolithic library collection. That's
> good for brand recognition around "Facets", but it also seems to hurt
> uptake b/c programmers tend to look for more focused solutions.
>
>

What about Facets as a brand, but not necessarily in the code
packaging?   That way, unrelated things are not seemingly related
in creating variables, requiring files, and such.  Then say "company"
Facets releases different, helpful packages.  (or whatever level of
granularity you like)

> Per the original query. I could subdivide the libs into taxonomic
> categories, eg. cliFacets, aopFacets, and what have you. That would
> help, but I worry it would still not be enough to spur this focused
> uptake. And I also wonder if it would still stifle development since
> they remain part a larger collective.
>

I'm sure you have covered all these, but my memory fails me sometimes
and I thought I'd bring them up.  The part that "concerned" me was that
I was thinking you (and/or others, in the general case) were talking
about doing something like this in the code:

require 'some_facets_file'

some_var = Ace.new
another_two  = Jacks.new(2)
fourth_and_fifth = Kings(2)

Then, I don't know whether I've just been dealt Two-Pair with an Ace
kicker, where the next line should be "raise 250", or if something more
useful is happening.

Sam
Trans (Guest)
on 2007-04-30 19:41
(Received via mailing list)
On Apr 30, 10:02 am, Sammy L. <removed_email_address@domain.invalid> wrote:
> >>> That said, I must admit I partly agree with you when it comes down to
> >> distinctly, and its quite ok to give them cute names.  But giving
> > files). The vast majority of which can stand on there own.
>
> What is preventing you from making them stand on their own?

For starters, maintaining 100+ packages would be a severe pain --
though I did seriously considered it. But really it gets too granular
at that point. We're talking about a lot of small generally useful
(albiet not necessarily commonly useful) libs.

> > I'd have to
> > be crazy to give each and every one a colorful name, but some of them
> > do admit of clear relationships, like the libs pertaining to CLI and
> > AOP.
>
> So, now you are looking to group them into more cohesive chunks?

Yes.

> > Presently Facets is one monolithic library collection. That's
> > good for brand recognition around "Facets", but it also seems to hurt
> > uptake b/c programmers tend to look for more focused solutions.
>
> What about Facets as a brand, but not necessarily in the code
> packaging?   That way, unrelated things are not seemingly related
> in creating variables, requiring files, and such.  Then say "company"
> Facets releases different, helpful packages.  (or whatever level of
> granularity you like)

Yea, I've been considering that option. It's a hard choice b/c many
people (including myself) tend to associate the extension methods
library with Facets --but that's just one part, albeit the core part.
So subdividing it in a _why-like way, I'm inclined to name the core
extensions package Facets. But that leaves me wondering if it makes
sense to also call the "company brand" (as you put it) Facets.

>
> require 'some_facets_file'
>
> some_var = Ace.new
> another_two  = Jacks.new(2)
> fourth_and_fifth = Kings(2)
>
> Then, I don't know whether I've just been dealt Two-Pair with an Ace
> kicker, where the next line should be "raise 250", or if something more
> useful is happening.

Sorry you lost me here. But that's a good hand ;-)

T.
Sammy L. (Guest)
on 2007-04-30 19:52
(Received via mailing list)
Trans wrote, On 4/30/2007 10:41 AM:
>> fourth_and_fifth = Kings(2)
>>
>> Then, I don't know whether I've just been dealt Two-Pair with an Ace
>> kicker, where the next line should be "raise 250", or if something more
>> useful is happening.
>>
>
> Sorry you lost me here. But that's a good hand ;-)
>
> T.
>

Oh, I was referring back to my original question of what the thread was
talking about.  I remembered there was a playing card reference
somewhere, and it "concerned" me if you were talking about naming the
classes after cards, then reading the code I might not know what was
going on.  That's all.  (aside from my typos in the example)

Thanks again for helping me understand what was going on.  I appreciate
it.

Sam
Michal S. (Guest)
on 2007-04-30 21:29
(Received via mailing list)
On 30/04/07, Sammy L. <removed_email_address@domain.invalid> wrote:
> >> another_two  = Jacks.new(2)
> >
>
> Oh, I was referring back to my original question of what the thread was
> talking about.  I remembered there was a playing card reference
> somewhere, and it "concerned" me if you were talking about naming the
> classes after cards, then reading the code I might not know what was
> going on.  That's all.  (aside from my typos in the example)
>
>
Also I would not want to search for a library named Aces. Nor I would
try as I usually search for solution to a particular problem, and Aces
does not sound like anything I was ever solving.

Although more capable search engines would also pick keywords from
description, I am not  sure about the current situation on Rubyforge
and elsewhere.

But I am pretty sure Facets never fell out of the search engines for
me. Maybe they are for stuff that I do not use. I don't know.

Thanks

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