New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alternate site generation concept #323

Closed
daveaglick opened this Issue Jan 5, 2016 · 10 comments

Comments

Projects
None yet
3 participants
@daveaglick
Contributor

daveaglick commented Jan 5, 2016

Alternate issue title: "oh, boy, what has Dave gone and done now..."

So I promised I would prepare a proof of concept for an alternative direction you could take for site generation. I finally got a couple hours to rig this up, and I think the timing is good since it looks like you're starting to think about more dynamic concepts (such as standing up an API).

First, a philosophical point: I personally don't think anything about this site requires anything other than a static build. That's debatable of course, but my own explorations have led me to believe that there are a lot of sites that could be purely static if it weren't for the limitations of their available tools.

Basically, I migrated the site to Wyam.

The repo is here (I didn't want to drop a PR bomb at this point): https://github.com/daveaglick/up-for-grabs.net/tree/master
It's live here: http://up-for-grabs.azurewebsites.net/

Right now, all functionality from the current site is implemented. It's a fully static site, including a minimum of JavaScript calls to outside services. For example, the issue counts are captured at build time and baked into the page.

In addition, some notes and additional features:

  • Pagination (#303) is currently implemented.
  • Processing Markdown in the project descriptions and rendering at build time is implemented (#288).
  • Gathering statistics at build time without the need for a database should also be relatively easy (#285) - my current thought here is that the "old" value can be fetched from the published site using data attributes, thus making the site itself something of the stats database (more on this later if we move forward).
  • GitHub rate limiting should be less of an issue since it'll get built once on the server and the clients won't need to all the API (#261).
  • You probably can't easily build it yourself right now - it uses the latest Wyam so you'd need to download that and build it from source before building the site. That's easily fixed down the line.

I also have some ideas on how to leverage the static build process to enhance things:

  • We could add a side pane that displays a project's rendered readme without leaving the site - we'd just fetch the readme HTML from the API at build time for each project and create a local HTML page for it, then load it via Ajax into the DOM when needed.
  • We could do something similar but for issues for each project - I.e., click a link and get a quick view of all the issues for a given project. In fact, I've already got the build storing the issues for each project, so we could even create a master issues list over all projects that would be sortable, pageable, etc.
  • We could improve the stats by showing graphs or sparklines with issue count changes, committers, etc. - all of which would be fetched at build time and then stored in the generated HTML for the next build.

The idea would be to set this up on a CI server that can build on commits and at regular intervals (perhaps every hour). I've already got AppVeyor scripts to do this for a Wyam build, but I would hope other CI servers would be similar.

Anyway, this was fun to take on. I've been wanting to try applying Wyam to a fairly complex build that wasn't mine just to see how far I got. Turns out it worked great. However, I recognize this may not be the direction you guys want to head, and that's okay too - I knew going in this was a bit of a flyer.

Eye candy:

2016-01-05_15h51_16

2016-01-05_15h50_56

@daveaglick

This comment has been minimized.

Contributor

daveaglick commented Jan 11, 2016

Had a couple spare minutes and couldn't help myself so I added Markdown processing and some rudimentary stats to the generation process:

2016-01-11_17h46_18

Next step would be tracking deltas for the stats and possibly graphing them over time as a sparkline or on a seperate details page for each project.

@shiftkey

This comment has been minimized.

Member

shiftkey commented Jan 12, 2016

OH MAN THOSE STATS ARE SO COOOOOOOOOOOOL 😻

I'll follow up with more serious remarks after I've had a chance to feed the inbox demons

@montogeek

This comment has been minimized.

montogeek commented Feb 1, 2016

Hi! Where is pagination implemented? I can't see it at http://up-for-grabs.net/#/tags/JavaScript

@daveaglick

This comment has been minimized.

Contributor

daveaglick commented Feb 1, 2016

@montogeek It hasn't been merged (or even submitted as a PR) yet. This issue was mainly to open up discussion on possibility and interest of moving to an alternate generator. You can view the results here http://up-for-grabs.azurewebsites.net/

@montogeek

This comment has been minimized.

montogeek commented Feb 1, 2016

@daveaglick Oh, I see, I like how it looks. I asked because I wanted to contribute.
So, we should wait for a PR to start working on other issues?

@daveaglick

This comment has been minimized.

Contributor

daveaglick commented Feb 1, 2016

@montogeek Not sure - to be honest, I'm not sure how much interest there is in bringing this in. It's a very big change to the current way the site is built and I mainly just threw it out there as a flyer. @shiftkey or another maintainer will have to weigh in on if it's worth developing further.

FWIW, the code used for this is on my fork in the master branch: https://github.com/daveaglick/up-for-grabs.net/tree/master

@shiftkey

This comment has been minimized.

Member

shiftkey commented Feb 11, 2016

Not sure - to be honest, I'm not sure how much interest there is in bringing this in. It's a very big change to the current way the site is built and I mainly just threw it out there as a flyer.

Yeah, and that's still where I'm at with the thinking on this:

  • we're not really using much of Jekyll beyond the _data stuff, but it's still rather mainstream for static sites (and should even work on Windows - not sure if Wyam supports other OSes)
  • getting site hosting and deployment for free with GitHub Pages is very nice
  • I got around to starting on my thoughts for how the API experience might work over in https://github.com/shiftkey/up-for-grabs-api-demo - it requires a separate server but I'm still a fan of having the data be separate from the rest of the content

@daveaglick thanks for putting together the demonstration on this. It makes me feel bad to say no at this stage to introducing Wyam but it was very cool to see what you had in mind for making the site experience richer - I'd love to pull in some of this as part of the API stats if I ever get back to that...

@shiftkey shiftkey closed this Feb 11, 2016

@daveaglick

This comment has been minimized.

Contributor

daveaglick commented Feb 11, 2016

No sweat - rigging it up actually resulted in some permanent enhancements to Wyam (like direct JSON and GitHub support) so in that regard it's a win regardless.

@daveaglick

This comment has been minimized.

Contributor

daveaglick commented Apr 4, 2016

@shiftkey Considering using this proof-of-concept in a talk about Wyam (possibly for Fringe). It's a great example of converting a fairly simple Jekyll site that also has metadata and custom coding requirements. Want to be sure you're cool with that?

@shiftkey

This comment has been minimized.

Member

shiftkey commented Apr 4, 2016

@daveaglick I'm absolutely fine with you talking about Wyam and your experiences here :shipit:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment