Great idea!

I didn't get a chance to finish work this weekend, if you need me to triage finishing up adding tests I can shuffle things around, otherwise we can integrate what is currently here, or move the merge/update to later in the week.

One thing to keep in mind: the more changes we make to the beautiful-jekyll theme files, the more difficult it will be to pull in fixes/updates to the theme if we ever want to do so. Not necessarily a problem, but something to consider.

I don't think the theme is particularly special or outstanding, and actually I don't think it (out of the box) is so great. I'd advocate for fixing to a better organization and maintaining most of the core style / design docs, and if there is some functionality that is added to beautiful jekyll that we want? Then we add it. I personally offer to do this - I think our daily usage / ease of updating the site and finding things is far more important than any tweaks for a simple web template.

If you are willing to do it, that's great. I was hesitant to make any significant mods because I'm not very literate in website design, but it sounds like you are more knowledgeable about such things.

I can start on the automated builds (for jobs) and testing, but first I want to check with @cosden if we would want to use GitHub Actions to do this? I can create the workflow on circleci for now, and then if/when an owner of the organization can request to be added to the beta, I can migrate it then.

@cferenba - good point. I think it's probably ok, as the updates are unlikely to significant enough for us to require them. I'm in the same boat as not being particularly literate with these things. That said some of the actions like the reorganization of the directory structure is definitely necessary. It was getting ugly.

@vsoch - I've never used actions and my personal account is on the wait list to get the beta release. The tinkerer in me wanted to try it out first before I attempted to offer an opinion. That's, realistically, unlikely to happen soon. It certainly seems reasonable, but that's based off the website description. I don't think it can hurt to request actions.

@vsoch : by the way, the custom.css file was completely created by me, so that I could make some minor tweaks to the theme without modifying the original .css files. Given that you're modifying those files anyway, it would work equally well to make those changes directly in the original files, if you think that would be a better choice.

hey @cosden I got fairly early access to actions, so I have a bit of experience and can share! It's not currently out of beta, and this means it shouldn't be used for (external to GitHub) services that would warrant even encrypted envars. However, for things that stay within GitHub (e.g., deployment back to pages) since we get a GITHUB_TOKEN envar by default, it's (in my opinion) a better solution than using an external CI (and needing to put a token there). Tokens can always be revoked, but you know, it's one more step to be extra careful.

@cferenba your approach is probably okay, it doesn't hurt to have more than one css file :)

And the waiting time is a crapshoot - I got it almost immediately, and I know of others that are still waiting. So that said, I'm happy to add the initial checks to the current travis, and the jobs page will be naturally updated with other changes to the site. If / when Actions is available, we can set up an automated nightly check. Does that sound reasonable?

I requested it for the org. I don't see how starting the request process can possibly hurt. My biggest concern is relying on anything beta. What if it doesn't materialize, or they change the business model to charge for it, etc? There are alternatives, so it doesn't seem like it would be the end of the world either way.

okay, that sounds good to me :) I totally agree, CI / services go in and out of style (cough, .travis) and as long as your builds don't rely on much more than "use this base and run these tests" it's fairly easy to migrate.

okay - I just pushed the files for circle, which we can use to do nightly builds. If someone that is admin on the repo can do as before and connect the project to circle, I should be able to start debugging.

Sorry - you asked about enabling circle a while ago didn't you...I didn't connect it for the blog, but I'll do it now.

No worries! It should be a matter of selecting the project "usrseweb" and then turning it on. I think circle (at least should be) smart enough that when we merge and rename the repo, the settings will persist.

@cosden one more thing to ask of you (I was able to do this for the blog repo because I had permissions, but I can't here). We need to add @manbat as a collaborator on the repo, he's my robot to deploy things.

We need to add @manbat as a collaborator on the repo, he's my robot to deploy things.

Done!

@manbat says thank you! A little history - his name is inspired from some of the comments here https://www.reddit.com/r/funny/comments/f95sz/what_is_your_batman_name/

I'll need to work a bit on the circleci build.

Note that the lbnl job posting (again!) went 404, so I just removed it.

Yeah, I just checked and it looks like the other posting is no longer open either. Nobody tells me anything around here... :-)

@cosden would it hurt to rename this repo to usrse.github.io now so we don't have to change it later? It's relevant for the URL that the static files render to (right now set to that).

Update 5/21/2019

Completed

• testing for the map data file is done now in Circle, we parse over the entries and ensure that each has required fields name, url, type, and coords, and then validate that the urls provided exist (image and url).
• testing for jobs data is also done - we look for required fields expires, location, name, and url, and ensure that the url exists, name and location are not null / empty string, and that expires is a datetime.date
• automatic generation of the site nightly is ready to go - since the build of the site will change the jobs page based on expiration, when jobs expire the page will build differently and they won't show up. Given no changes, the push will just alert that there is no change.
• GitHub Actions will be pushed to some future time when we get repo access.
• The site preview looks good. When it's time to change the repo url (so that the domain can serve all "subpages" like /blog, we can tweak the circle_urls.sh script to not hard code the name.

This is now ready for review.

I'm not sure about the jobs part either, but I think the worst thing we could do is to have a page of old posts that either don't work or have past the dates that they say are their deadlines

Ah, I added the expiration date to the interface after we talked about it in slack, and didn't think that it might not be desired to actually show (note that it's used to know when to remove the job from rendering on the page). We can very easily not render it on the page! Would this be desired?

To jog your memory:

okey doke, I replaced the expires with the location (makes sense, right?) https://14-120906408-gh.circle-artifacts.com/0/usrse.github.io/jobs/index.html

what do we do when the work could be remote?

The user adding the job would just add location as remote, e.g. any of the following:

- name: Top Dinosaur Job
  location: Remote
  url: http://www.dinosaur-jobs.com/1
  expires: 2020-01-01

- name: Top Dawg Job
  location: Boulder, CO or Remote
  url: http://www.dawg-jobs.com/1
  expires: 2019-08-01

What about putting a "posted" date instead of an expiration date?

The ideal would be for expired jobs to be removed in a reasonable timeframe, but reasonable isn't always as easy as you'd like. The two LANL jobs I posted expired within the last week, but I knew nothing about it till others found the links broken.

We could add a posted date, but it seems not so useful given that the person reading has no idea when it expires. If the goal is to get the post to automatically show up and then disappear when it’s old, if we only had a posted date we would require all jobs to have the same duration. Or we would have to force the poster to specify a duration along with a posted date which seems excessive. It’s simpler and cleaner should just ask for an expiry date.

The implicit knowledge is that showing up on the page period indicates not expired. Perhaps it would be better then to add a note to tell this to the reader?

Just snuck in the GSB group at Stanford, who just got back to me they want to be added!

oooh wait! I need to update the README with docs for how to add stuffs!! Do not merge!!

In the end, I don't think there are enough eyes on the site (at least not yet) to let perfect be the enemy of the good! We'll inevitably iterate as time goes on and this is clearly a very big step in the right direction. I can merge tonight if no one else objects or if someone wants to go ahead and do it, go for it.

okay, looks like we are good again!

I'll merge now so that I can check that everything looks okay when it updates gh-pages. When I've confirmed that, I'll merge USRSE/blog#20 to remove the map from the blog site. Thanks y'all!