working on the dlang.org website

[Val Markovic]

This discussion seems to have gone off track.

I pointed out three things that I thought should be addressed to ease the
use of contributing to the dlang.org site (and other D-project components),
and those three things were: a) lower response latency on pull requests, b)
better documentation of the component "plumbings", specifically how to
build the dlang.org website and c) README files in all the D-project repos
with answers to common questions outside developers might have, like "where
do I report bugs?".

The discussion here goes on to debate the pros and cons of ddoc which is *
explicitly* something I mentioned as "not worth fighting over". Yes, IMO
it's an unfortunate choice of a markup language because to outsiders it's
esoteric and unlike most other markup languages and there are far better
options out there (Markdown or reStructuredText). For a project that's
still looking for contributors it's just another roadblock to adoption.
It's what they call an "unforced error" in tennis; something that makes it
harder to succeed for no benefit or reason, and not doing it (or doing it
differently) helps you get to where you want to go faster.

But again, this is beating a dead horse. This mailing list has seen plenty
of discussions on the topic and the powers that be haven't been convinced
to move away from ddoc so I don't think it's going to be fruitful to debate
this further. Let's be practical and let it be and move onto other, more
important problems. Nobody has ever said "Oh that D language is great but
ddoc is so bad I've decided to use Java". That just doesn't happen. It's
not that important.

Ddoc was irrelevant to the changes I wanted to make to the site anyway. The
more important problems I listed were the ones preventing me from making
them.

Other points:

1. Having the website inside git on github was a great idea. Walter made
all the right arguments explaining why.

2. Makefiles are fine, but there needs to be a README saying "hey go run
that posix.mak file" because there's no "Makefile" file in the site repo.
And then the makefile has assumptions about its environment which are not
documented anywhere. It's not obvious what needs to be done.

3. Ruby on Rails (or Django or any other web framework that dynamically
builds a server response) would be a terrible choice for a static website.
It would be nothing but overhead for no benefit. Nothing on dlang.org is
dynamically generated, nothing talks to a database (nor should it). The
site can and should be generated from some simple markup language. The end
result should be HTML, CSS, JS and image files that are then just served by
the simplest of servers. For these types of sites, the industry standard is
quickly becoming to serve the files directly out of Amazon S3 with a CDN
(like CloudFlare) in front of it. The end result is an incredibly fast
browsing experience because everything is just served directly out of the
CDN edge servers without any kind of dynamic response generation. Requests
come in for files and the CDN just echoes them out of memory to the network.

Of course, forum.dlang.org would be different, but (internally) that's a
different site entirely.


On Sun, Jul 14, 2013 at 1:35 PM, Walter Bright
<newshound2 at digitalmars.com>wrote:

> On 7/14/2013 6:49 AM, Dicebot wrote:
>
>> But maintaining
>> whole stuff via git repo + makefiles is definitely cumbersome, no idea
>> why that
>> was chosen.
>>
>
> 1. github is how the entire rest of D is maintained, it would be strange
> if the website was handled via some completely different system.
>
> 2. github is of proven utility in enabling anyone to contribute to the web
> site via pull requests.
>
> 3. github/makefiles are how everything else in dlang is done, so
> contributors should already be familiar with the process.
>
>
> As for using Ddoc,
>
> 1. It relies on D being installed. Presumably, anyone interested in
> developing the D website already has D installed. No other tools are
> necessary.
>
> 2. Ye Olde Dogfooding argument. Experience with the web site has driven
> some good improvements to Ddoc.
>
> 3. HTML, PDF, Ebook, and CHM outputs are generated from Ddoc.
>
> 4. Website can be built on any platform that supports D.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130714/7eb5eff8/attachment.html>