My last blog post was on a newly acquired skill and when I reflected on that I got an idea for a blog post on how I, most of the times, process new skills, technologies and learning.

I have written quite a few blog posts on getting going with GitHub Pages. I even made a sort of roadmap for what I wanted to explore.

Firstly getting started with GitHub Pages, was mostly by accident, stumbling upon GitHub Pages, identifying it as a good solution to my immediate needs in this space.

Can I use GitHub Pages for websites for my different open source projects, primarily Perl distributions

But the roadmap that emerged looked as follows (all made it into blog posts).

1. Extending GitHub Pages with a little JavaScript, getting JavaScript up and running, sort of ignoring the normal GitHub Pages setup based on the README.
2. Processing external data for a GitHub Page setup extending the JavaScript use with calling an external API (the solution above made use of local data)
3. Putting it all to use, basic DOM querying and manipulation in what is not a prototype, but one of my existing pages, which could do with some spiffying up

This all concluded the first milestone for this roadmap I set up for myself. The first post had actually outlined a more ambitions roadmap.

• Jekyll, getting more from the standard and by GitHub chosen static site generator
• Hugo, evaluating the use of an alternative static site generator
• Vue, not limiting implementation to vanilla JavaScript
• React, again not limiting implementation to vanilla JavaScript
• Svelte, and yet again not limiting implementation to vanilla JavaScript
• D3, perhaps even doing beautiful visualizations or graphs

One could argue that the first posts, where on topic for getting to learn Jekyll better and see what was possible with vanilla JavaScript on GitHub Pages.

You should be able to spot a pattern at this point

When I picked up GitHub Pages, I followed the same pattern of repeating the implementation across different projects, meaning that my newly learned skill, was repeated several times, in different contexts or at least minor variations to the somewhat the same context. The result was:

• My Perl distribution Test::Timer
• My Perl distribution Date::Holidays
• My Today I Learned repository
• And my personal website at: jonasbn.github.io

This resembles very much computer games as such, where you have a primary goal with a main story and a plethora of side-missions.

My first level was answering the question:

Can I use GitHub Pages for websites for my different open source projects, primarily Perl distributions

The side-missions where outlined above and I still have several side-missions I have not yet completed, but the next level is simply too interesting.

Can I use JavaScript on GitHub Pages for making these more dynamic

The ultimate ambition for this was D3, since one of the side-missions for the first level sparked the idea of making a visualization using D3, for one of the specific websites completed as a side-mission.

Then, again by accident, I fell over the stream: "Let's learn Nuxt!", which introduced me to Cloudinary and a new side-mission revealed itself.

Can I make images used on my GitHub websites responsive using Cloudinary

As I blogged, I think I succeeded.

This opens up for a number of side-missions, where I need to evaluate whether Cloudinary can benefit some of my other websites or get me going with the missing side-missions.

Another side-mission, which could be added could be to add Nuxt to the list of frameworks to evaluate in the context of GitHub Pages.

As you can see there is a nice patterns to learn and evolve gradually and iteratively. Some of the improvements are smaller and some are giant leaps, but the important thing is constant progress and in my opinion this approach holds the following benefits:

1. You can set a goal and some milestones leading to your goal
2. You find out if your milestones can be reached (learning that it can't can also be a learning point), but keep your milestones small and realistic, especially if you like me have limited time to set a side
3. You get to solve minor bumps in the road, which you did not anticipate, I got Jekyll running locally and got into using Ruby Gems as a bonus
4. You can iterate and learn in small steps and focus on small problems/milestones to keep you going - you need the successes
5. You can reach your goal, one milestone at a time, always build on top of what you already have

This all sound very disciplinary and well ordered - Well it is not.

• You run into bumps in the road you did not anticipate and they take what little time youhave - consider if you can work around them
• Oftentimes you dig too deep and you loose track of your milestone and goal
• You will get sidetracked by the amount of opportunities, get them into your plan, if the do not fit, perhaps they should be abandoned
• You will loose focus and you will procrastinate
• Software and software development is hard and learning is tough

Some final advice:

• Do not be afraid to step away, go for a walk, sleep on a problem
• Do not be afraid to throw your stuff away and start over (git is your friend)

Thanks for reading to the end. Please Share your roadmap with me, share your progress with me. I might not be able to help you with your exact problems, but I can listen and act as rubber duck debugger.

This post go be quite wordy, I wished I could express this more graphically, so just for inspiration, do checkout this Go Developer Roadmap, which is just awesome.

Expressing roadmaps this way should perhaps be my long term goal.