Re: WebPlatform static pages are now on GitHub!

Hi Jen,

Yes!

I should hop on this project soon enough. I'd like to finish up with the
compatibility tables before going with my suggestions. That might be a
bigger project because it implies changing things also in MediaWiki
(e.g. the _WPDwiki.scss[4] cannot be like that, more at [5]).

In the meantime, we can deploy your work as is, but probably with some
adjustments that are unknown to you, but are required. Small things;
i'll fix them myself and push to github.

See inline for the explanations.


On 3/7/2014, 12:54 PM, Jen Simmons wrote:
> So, Renoir,
> It makes sense to me to make this repo be *the* repo for everything at web
> platform.org, and not on any other domains. 


I feel the same; let's rework things.

But I think the workspace should fit two distinct use-cases: serving
production content, and a workspace. Some files don't need to end up in
the production server at all (e.g. the sass/less and non minified+linted
js files).

This means at deploy time, we pull the code, compile sass, lint js
files, delete some folders, then rsync them to the servers.


> (Easy enough since there's code
> for two sites in this repo currently, and we plan to delete one site —
> talk.webplatform.org).


It'll be deleted, no worries.

Lets just plan what we should do with the URLs (redirect permanent?) and
content. Because... "Cool URIs don't change".


> If this repo is the repo for everything on the main domain,
> www.webplatform.org, then there's no need to merge part of this into part
> of something else or copy (without git) pieces of it onto the server. It
> will be clear for anyone that ever clones this repo to work on it why all
> the moving pieces are for everything at www.webplatform.org. That kind of
> clarity would be very helpful.


I agree. We have to work that out incrementally.

But we have to have an easy to install workspace that requires less as
possible softwares to install for the contributor.


> As it is now, with different repos getting merged together in some unknown
> way — it's very hard or impossible for different people to help keep things
> organized. I've already reorganized the stylesheets and the asset directory
> structure, but because I don't know what's going on on the server, I don't
> know what I might break with such a change. By having multiple websites in
> one repo or multiple repos for various parts of a single website....


Because our site looks like a single website. But its not exactly like
that, its using many components together. Making things obvious and
pushing more (and documenting) the deployment process on github will
help clarify.


> everything becomes a mess. A mess that you have to clean up, or that only
> you understand. And I hate single points of failure, this should be dead
> obvious to multiple people.

I have the same feeling about that.

In fact, I have some ideas too about things we can do to improve; ones I
already briefly described above.

If I may suggest, I'd ideally use the www domain to serve a small
footprint set of files and make the other applications use them from
there. That's one more reason to agree with what you are saying.

Also, when somebody merges on master, it would trigger a "web hook" that
automatically minify, sync files to all appropriate servers, send a mail
to the list whether it worked or not, and even to clear caches (Fastly,
Memcache, etc).

That way, we would be able to use the already-in-place caching that www
has.

The nice thing is that we might gain some performance not only because
we wouldn't need to rely on backend code, like it is at the moment (!!),
but also in HTTP caching because it is also cookie-less domain.

[5]: At the moment, the CSS is scattered around and gets minified by
MediaWiki asset manager. What saves us in this is that we configured
Fastly to keep the generated CSS cached and to prevent re-generating at
every request. In essence, that's the backend code, called through
`/w/load.php?...` that is served throughout all the site. When the
mediawiki backend breaks, all other pages breaks, even the ones not
relying on mediawiki.

... and caching is not optimal either.

Talking about scattered around, even some CSS is picked from a wiki page
(!!). That has to change too...

That's what I was talking about when I showed you my static styleguide
[1][2] when you arrived, and also when I started this job last september.

And coming back to the the barrier for the contributor. We could have
backend-less workspace with a tool such as RoughDraft.js[3] that I used
on my own static styleguide.

I can help with that, but that'd be in a different thread.


> What do you think? If we agree, I'll set this repo up to be *the* one and
> only repository of everything at www.webplatform.org. Then all we have to
> do to launch is clone this repo to the server (or grid) that serves
> www.webplatform.org and pull. Any time we want to make an update, all we
> have to do is pull. We don't have to merge some crazy thing first. Just
> pull.
> 
> Yes?
> 

I think I said it all. I probably overkilled the "how to do" though.


  [1]: https://renoirboulanger.com/styleguide/
  [2]: https://github.com/renoirb/renoirboulanger-styleguide
  [3]: https://github.com/ndreckshage/roughdraft.js
  [4]:
https://github.com/webplatform/static-pages/blob/home-page-redesign/sass/_WPDwiki.scss

-- 
Regards,

Renoir Boulanger  |  Developer operations engineer
W3C  |  Web Platform Project

http://w3.org/people/#renoirb  ✪  https://renoirboulanger.com/  ✪  @renoirb
~