Seminars: YAML→{HTML,ICAL} instead of ICAL→HTML?

[ebousse]

At the end of 2022 I set up a new page for weekly seminars, whose HTML gets automatically generated from an ICAL calendar hosted on Nantes Université Zimbra. The goal was to make it easier for me to manage the schedule of seminars, and ICAL seemed a good idea since it allows me to create seminar slots directly in a calendar app.

However, I am now unsure about this decision for different reasons:

1. We cannot build the website if the online calendar is down (I think)
2. The content of the ICAL calendar is stored in a different place than the website, which means that a given commit in the present github repo does not fully embody a complete version of the website at a point in time. In practice this e.g. means the website must be re-built when the calendar is changed.
3. The calendar is not stored on a versioning system such as git, which makes me anxious at the idea of deleting parts of the online calendar by mistake, which would be very sad since we would lose forever the history of seminars.
4. The lib I chose to parse the ICS file is not that great, and require us to cheat to manage the data about the speaker (currently stored… as a location in the ICAL event).

Therefore I am now considering going back to a system similar to the previous seminars page originally developed by Florent around ~2018, and still available in this file. The system was simpler: a huge YAML blob with all seminars, and HTML smartly generated from this blob. While it would not allow me to edit seminars in a nice calendar GUI, I would feel safer to know that everything is on git. Moreover, there would be no "desync" between the website and the ICAL.

Yet, because I still like this ICAL file (!), I'm considering implementing a small Jekyll extension that could produce ICAL contents that the Naomod website could still host as a URL, or use to display a graphical calendar view on the page. This still maintained Ruby lib could do the trick to implement that easily, I think.

In any case I'll get back to this once I have time, just writing and sharing thoughts for now :)

[ArtemisLemon]

Alternatively to huge YAML blob: using the _post folder and the blogging idea of jekyll, each seminar could be represented as a "date.markup" file.
https://jekyllrb.com/docs/posts/

next are just some discussions from people trying to do posts -> ics and the like:

• Add calendar page with Jekyll posts and exportable ICAL feed sustainers/sustainers.github.io#275
• https://stackoverflow.com/questions/32902209/how-to-create-multiple-pages-per-post
  -- https://github.com/saclark/jekyll-multipost
• we might be able to build the .ics like any other page https://github.com/berlinphp/berlinphp.github.com/blob/master/calendar.ics

[ebousse]

Alternatively to huge YAML blob: using the _post folder and the blogging idea of jekyll, each seminar could be represented as a "date.markup" file.
https://jekyllrb.com/docs/posts/

Looks good to me.

we might be able to build the .ics like any other page https://github.com/berlinphp/berlinphp.github.com/blob/master/calendar.ics

Oh this is cool, then no need for a specific library, I like it

But can we ask Jekyll "please loop over each post and use the post metadata to generate this"?

[ArtemisLemon]

If I've understood that berlinphp was going, they've got a loop to make an vevent for each post

METHOD:PUBLISH{% for post in site.posts limit:3 %}
BEGIN:VEVENT

then it gets the post yaml variables i believe to pass around the meta-data

SUMMARY:{{ post.title | remove: ',' | remove: ';' }}
DTSTART:{{ post.date | date: "%Y%m%d" }}T170000Z

[ebousse]

Brilliant!

[ArtemisLemon]

I'm thinking a one time script to get the .ics into a collection of .md files, then move on from there?

[ebousse]

I'm thinking a one time script to get the .ics into a collection of .md files, then move on from there?

Sounds great. You can add said script somewhere in the repo in a scripts folder or whatever, just in case.

Good luck!

[ebousse]

Fixed by #29