Michael C. Libby wrote:
Often it's easier to write a new application from scratch then understand an existing one. By writing Wee from scratch, I learned *why* Avi (who wrote both IOWA and Seaside/Borges) did the things in this way. I used Avi's ideas and implemented them in Ruby how I'd implement them.
Beside "writing your own" as a learning experience, another thing not to underestimate is the ludic aspect of all this. A lot of open source project are simply for fun, not for profit nor "efficiency".
Yes, exactly. It is fun, and you can learn a lot of things in doing so. I personally want to understand the underlying libraries before I like to use them. So this is what I did with Wee 
Sometime, even though there already exists uncountable "solutions" out there, I just feel like writing my own as a hobbyist. Just because I can :o)
Seems to me that web sites are often highly customized animals, as well.
But they can IMHO be grouped into two categories:
* web *applications*
* web "sites"
Web applications are much more like GUI application are, just that the browser
is the GUI, whereas web-sites are more like traditional sites, with some dynamic stuff in them. From my point of view, web applications need registration and are build with a limited number of users in mind (you develop these kind of applications for a compary for example). This is my definition of "application" vs. "site", it may be wrong for someone else than me 
Wee is very well suited for applications, whereas Rails and Nitro are better suited for dynamic sites (with many users, but not so much interaction and UI-state).
Might make less sense trying to fit the design into an existing framework
than it does to just build something that does exactly what is needed for
the case at hand.
Part of the problem we have with Ruby is that writing new code that is fairly powerful is very, very easy. This is a good problem to have. 
Of course, this also means that it might be easier to simply code from
scratch than figure out how to extend existing complex code. With Ruby
this is less of a problem than some languages, but big projects are still big projects... and that can be intimidating (at least to me).
Hm, I don't think it's easy to develop Nitro or Rails from scratch. And they are good for most purposes, so unless you want to take a different approach, you would not want to write them from scratch.
I also want to suggest that the names chosen for most of these projects
aren't particularly helpful, nor are the descriptions. This means that people like me, who tend to get glazed eyes fast when anything that looks even remotely buzzword compliant or marketing-flashy comes along,
may miss a perfectly useful package simply because it has a "wierd" name
or the description is too vague. I'm sure this is just prejudice on
my part, but I tend to avoid stuff that comes across like an ad in Dr. Dobbs for the latest Java gizmo or the newest .NET snake oil.
Which name(s) do you have in mind? 
That's why I like to see examples in their description. The best description for me is an example. You can quickly see it's beauty and simplicity from an example.
Is it possible the names make people think of a package as someone's pet
project rather than a community resource to be hacked and extended?
Wee is for sure a pet-project, at least it started as one. But IMO, it has potential for very dynamic applications. And if you take a look at the sources (the core), you'll see that it's pretty well documented and easy to understand.
Regards,
Michael
ยทยทยท
On Fri, Jan 14, 2005 at 08:49:54PM +0900, PA wrote:
On Jan 14, 2005, at 12:42, Michael Neumann wrote: