Description

Easy to configure and reuse Jekyll site which showcases your GitHub repos by topic keyword

Add instructions around it saying you'll get errors on the first build and have to update token then rebuild.

To save space, perhaps shorten to first few, or show on hover over.

Click the link to go to the topic elsewhere in the page (or jump to topics page from repos page).

See Bulma Fontawesome use

This can be useful as links to pages, or a choice of filters.

For example Python projects, ML, Javascript, Templates/Quickstarts

the label can be different to the tag

consider AND logic such as JS + Quickstarts.

This makes it more focussed for me (avoid the long tail) and targeted as portfolio of skills. And for me to find things or a share a link.

Even if its just basic Github Pages markdown.

Link to the content from the main site.

Keep them separate though. The main site is for people use consume info, not to the project code.

Site data comes in as repos list. Convert to a hash.

Output will be topics with name and hash of repos. Which can be ordered later by a field.

Data comes in as list as repos from gql
Iterate over that and the topics. In the output, add a topic key if one does not exist. Give it a topic name and empty hash by default. Then add a repo by user and repo name key, using site data as value

Now you can loop over topics and get repos in each, which need to be ordered after processing is done but possibly avoiding sorting just before you use it, or ordering is consistent style. You can even stored date sorted version and name sorted version though you might store a topic that is never used.

You can also look up a topic by name from frontmatter and then show its repos. Probably ordered by date. Maybe by name. There should be an elegant way to switch even if JS shows and hides.

Possibly using a JSON file for data that is read.

See also PrimeVue or StyleComponents

Use OR logic

base
starter
quickstart
skeleton
scaffold
etc

Just a projects, not under topics. And then those can be excluded from the topics page maybe if I can find another view to see distribution of each so I can use the same keywords on all my quickstarts

With API endpoint locally or with cron service as per article

https://community.netlify.com/t/scheduling-builds-and-deploys-with-netlify/2563/5

Even weekly and not daily.

• Use bulma for sticky header
• Remove footer
• Use CSS-based Bulma accordions to switch between keywords - avoid having to use droplist or radio and removes need for split between form and result. Note - this only works for tags view.
• Remove chosen keywords from frontend

Add Github link in the top right corner.

There are a couple things I don't like about this and a clean start could be nice.

Refactor the GQL to use a Python script and appropriate library. So don't have to refactor and maintain ruby.
Maybe write to a separate file to separate the logic. Fewer fetches at development.
Also add paging, based on my reporting repo. Maybe a library makes this easier or maybe not and it just makes other code simpler
Use Netlify or GH Pages/Actions workflow. Use deploy token or otherwise GH token for GH Actions

Build one view of my repos with topic filters at the bottom. See link from Joan.

Repeat this pattern for my starred repos.

These are for me currently working on as quick reference, in an order I set - not necessarily to show someone.

Use ListJS. Add name search. And filter to starred Y N or forked Y N.
To solve the name issue try forcing ascending https://stackoverflow.com/questions/32246782/list-js-default-sorting-table

For follow up use keywords for repos page or topics page and a short script to filter using radio or checkbox. Radio is simpler.

https://stackoverflow.com/questions/34905974/list-js-filter-by-radio-button

Later add for topics page

Since filtering will not work

They are for difference audiences.

See what content should be duplicated or not.

Should setup instructions be on the website itself? Rather make it focussed on presentation to most people and rather include a short setup section with a link to docs.

Even consider a separate Github Pages docs site (Jekyll or Docsify), but that is not important. Esp for short docs.

Using GITHUB_TOKEN already.

Filter by repo name or tag from droplist/radio.
Perhaps prefilter to topics to preferred ones or exclude some.

And for another issue:

And then a new kind topic page can be used to highlight without filtering and just selected topics, with images and set order. Perhaps split out each onto separate pages or find a way to navigate between all easily. Perhaps treat like a blog post where there is a preview of the recent or top rated in Python and a page to see all of them.

Maybe the topic and repos can be curated so not based on tags at all. Just before of repo names breaking but it is central to build a portfolio. And also use to make a quick reference page for me whether current topics or just topics I care about (Jekyll / Netlify) which might not make sense as hiring portfolio.

Or move them to separate section in frontend or query.

For created and modified dates, add bracket numbers or tooltips

Logic:

days = Current date minus target + 1
If less than 7 days then "days"
If less than 28 days then "weeks". Days / 7 and round off.
If less than 365 days then "months". Days / average month
Otherwise "years". Round off.

When selecting top of repos and topics to put them in, check if the repo names in the data / config file are all in the fetched repos list. Otherwise fail the build. This helps to keep track of repos that get renamed.

Do this in Ruby. Use sets - take the configured list and subtract the larger list and see if there are any items left.

Such as when pressing back. So it filters without keyup

Consider the existing github dev portfolio name. Add my maybe

Remove CSS then.

Greyed out. Use for repo and topic pages

It should wrap neatly
And not require breakpoints
And use full width on mobile

Separate the handling of the fetched data and of doing the request. Maybe find a plugin for the later.

Keep using Ruby

Convert to external gem installable.
Refactor that to separate concerns

Allow passing of argument / env variable for dev mode to restrict items

Also look at paging for repos > 100