Open thoward opened 8 years ago
A few quick questions about this as overhead...
Anyway, just adding some thoughts here.
So, I'm not sure if you're asking "should we have a video.nodepdx.org site at all" vs "should we have it be static or richard". I'll address both.
According to the logs, we get about 50 hits a day of normal traffic, and about 50-60 of crawler traffic. So, it's pretty low traffic, but still interacted with on a regular basis.
Re: "should we have video.nodepdx.org at all?"
So the alternative is just to have a bunch of loose videos on YouTube, and possibly collect them with a list, or place them under a NodePDX account (they are currently under the NextDayVideo account, which has tons of different videos for different conferences). The downside to that is a lack of a single destination for all videos, and a lack of a unified/branded experience/canonical URL to get there. I think it's worth maintaining the index page and per-talk notes with descriptions, links to the slides when available, etc. Also worth noting, we're not hosting the video, just embedding it from YouTube, so it's pretty lightweight. We basically just need to serve up some HTML to accomplish this.
We COULD curate the videos on YouTube, under a NodePDX account, with lists for each year, and redirect video.nodepdx.org to the YouTube user landing page... but I think that'd be a mediocre experience, and basically just as much trouble.
As for "richard vs static" .. The idea is that static would be simpler to maintain than a Django web app, and offer the same experience. In fact, it'd be more reliable as well, since GitHub Pages is less likely to go down than my one-off, unreproducable digital ocean box (actually, I think there are some backups somewhere, so wouldn't be impossible). Richard is handy for integrating w/ NextDayVideo's process, but it's overkill for our use case, and I think a simple static site generator could accomplish the same task from veyepar json, and it'd be better for everyone.
Ah. That all makes sense. I'd +1 a static page to handle this and definitely keep a branded page vs. going to a list in Youtube.
Currently, http://video.nodepdx.org is running Richard (https://github.com/pyvideo/richard). This platform is convenient because it integrates with @CarlFK 's (NextDayVideo) veyepar/richard workflow... but really, we're not getting much benefit from that, and it means maintaining a Digital Ocean droplet running Django on a constant basis vs just serving static HTML. There's a cost involved in terms of money, but also in terms of mental overhead and remembering/documenting all the details of how to maintain that server. Static HTML served from GitHub Pages, with a simple generator script to update it would be much easier.
We can get JSON from @CarlFK 's veyepar platform (https://github.com/CarlFK/veyepar) and use that to generate static HTML. Since we're not using the cataloging and searching features of Richard anyway, this would produce the same experience for the end-users.
An example of the NodePDX 2013 video data JSON is here: http://veyepar.nextdayvideo.com/main/C/troy/S/nodepdx2013.json
Working from that output, try to replicate the Richard site at http://video.nodepdx.org. The JSON should be captured and stored in the git repo as a
.json
file for long-term archival use because it's possible that it could be deleted from veyepar whenever Carl feels the need to do that.Tooling should be something node related, or just implemented in Bash. I don't want to have to install Ruby v9.3.40-magicbuild and some conflicting gem to generate the site (I'm looking at you Jekyll).