[SGVLUG] Website Testing

[David Lawyer]

On Wed, Jul 20, 2005 at 02:13:10PM -0700, Emerson, Tom wrote:
> However, "out of the blue", I found sgvlug.org mentioned in an
> e-mail captured in this archive:
> http://mail-archives.apache.org/mod_mbox/httpd-docs/200104.mbox/%3C3AE64DD9.6EAB8DAF@earthlink.net%3E
> 
> In particular, the comment is "[example websites]... sgvlug.org --
> is kinda boring"

I saw this too when I was checking out some links to sgvlug.org.  I
think the person who wrote this is wrong.  Our site quickly, simply
and rapidly provides info on sgvlug.

> 
> ouch -- we're "boring" -- no wonder attendance is down ;)
I've mentioned before that I've gotten a some enquiries asking if we
still exist (emails and phone calls to me).  For every one I get there
are perhaps about 10 others that find our website down and just assume
we likely don't exist without even knowing that I was once the contact
person (and perhaps still am).  So I think that attendance is down
because of our website failure.

> > This is one reason I don't much like html editors.  While
> > machine-generated code is a tough problem in general, I've always
> > had the private conviction that it wouldn't be that hard to
> > generate much more readable code.

There's also the universal markup method which is something like an
html editor.  You create a page in say docbook or linuxdoc using vim
and then run it thru a filter to get hmtl, plain text, pdf, etc., etc.
Docbook is a very powerful markup language but why use it to create
html pages when Docbook is equally as complex as html.

> That's one of the secrets -- you need to consider an HTML page to be
> "code", and apply stylistic techniques for "maintaining readable
> code": indentation, comments, and even fully blank lines where
> appropriate.
> 
> > Note that I'm *NOT* advocating maintaining the site in nvu.  I
> > merely point out that if static pages are more important than
> > anything else, that is probably the only alternative to
> > 
> > > editor (=vi) of course.  At least 2 people would need ftp (or
> > > ssh) access to maintain the webpage.

> The problem with using "just a plain text editor" is that once you
> get to "more than one person doing the work" [or even "one person
> using more than one computer"], you need to invest in a
> revision-control mechanism of some sort anyway -- otherwise you'll
> get changes overwritten by "the other guy with the older version of
> the page..."  

Not if you use the copy on the server as the master copy and update
it by editing with vim via ssh.  One could log their changes inside
an html comment and keep a history of changes there, to be removed
every couple of years when it becomes too large.

There are other ways too.  Suppose we have two co-maintainers, each one
of which agrees to maintain the site for a 3-month period and then
take 3 months off.  Or they can negotiate between themselves for
variations: one fills in while the other is on vacation, too busy,
etc.

Also there can be two or more ssh login accounts on the server.  Each
SIG webpage could be maintained by a different person using a
different ssh login and each one would only have modify access to one
SIG webpage.

So there are simple ways to do this for sgvlug without any revision
control system.

> > This is exactly why I am opposed to maintaining raw html, whether
> > with vi or a fancier editor.  I think ease of delegation is worth
> > dynamic generation

But as I explain above and Tom explains below, sharing the work
doesn't require a dynamic site.  For the Linux Documentation Project
(LDP), the hosting site would not allow the use of Plone, partly due
to alleged excessive bandwidth needed by Plone.  Part of the problem
was the fact that the person that was hard at work to make Plone
suitable for LDP became seriously ill and may die.  LDP is an example
of a site that needs CMS (hundreds of authors, etc.) but for sgvlug,
I'm not so sure.

> As such, the "editing" that I've been doing (and I presume Michael
> does this as well) has been ON the target system via vi -- while
> this reduces the likelihood of an overwrite, it also means I've been
> editing the web page in real time.  OTOH, we're now running into
> permission problems if either of us forgets to make a page
> "writable" by the other.  [though this can lead to security problems
> if that's the same "group" as the web service itself...]
> 
			David Lawyer