Testing Static HTML!
One of the benefits of generating a site as a static artefact (here using Jekyll but there are a gazillion tools) is that the finished product is a known quantity. Anything that's a known quantity can be tested!
Yarn!
Yarn is a new JS package manager that promises to be fast, secure, and reliable. My initial experience is that it is fast. I'm excited about making time to use it for real at work. Kudos to the developers!
Adding Structured Data to a Jekyll site
Structured Data is a way of adding context to files served on the web so that computers (primarily but not only search engines) can respond to what your content means.
Google, for example, will alter and improve how your site appears in search results based on the context you give your data. And if your site is considered authoritative can use the data to build the knowledge cards it sits alongside other search results.
This blog is only authoritative for being unread but I've not worked with structured data and thought I'd investigate.
Using Travis CI to build a Jekyll site
<aside class=""mb-2 ml-4 border-l-2 border-l-sky-700 pl-1""> <h1 class="text-base">This post is part of a series on improving this blog #recursion</h1> <div class="flex flex-row"> <div class="flex-grow"></div> <div class="flex-grow content-end"> Next Post </div> </div> </aside>
I recently had a conversation where I said that I couldn't build an AMP version of my blog because I use Github Pages to build and serve it. Github don't allow any Jekyll plugins to run.
Later that day my subconscious prompted me to realise that, since Github pages will serve static HTML quite happily, I could use Travis CI to build a Github repository that held the source for the blog and push the static output to a second repository that Github would publish as is.
Remove If With Objects
Today I had super-fun spotting the opportunity for a refactoring and figuring out how to apply it. I wanted to think it through while it was fresh in my mind to try to cement any learning opportunity
The refactoring in question is "Replace Conditional Dispatcher with Command".
Quoting that source the opportunity for this refactoring is when:
Conditional logic is used to dispatch requests and execute actions.
And the solution is:
Create a Command for each action. Store the Commands in a collection and replace the conditional logic with code to fetch and execute Commands.
It's one of those subtle changes that has real power to tidy up and add to the expressiveness of your code.
If (pun intended) you aren't familiar with it I'd definitely recommend trying it on for size by looking for an opportunity to apply it in your systems.
Powershell on Linux
MS have open-sourced powershell and made it work on many platforms. Kudos to them - I'm loving the "new MS".
I've never really got powershell. Although it's definitely an improvement on vbscript so I have used it when I've needed to automate windows.
But as a task approaches some ill-defined level of complexity I switch to C#, Ruby, or Node rather than writing a script. Not that those are the only options but I don't know Perl, or Python, or $yourFavouriteTool.
As a result I have barely written any Powershell on Windows and, as I've done more work on Linux over the last few years, I've also barely written any bash.
So, while I think it's a good thing that MS are opening up and releasing cross platform tools I was underwhelmed. But…
Real vs. Software Engineering
I recently had some "fun".
Earlier this year we got a great deal on two ducks, three chickens, a coop, a run, and Gary the Rescue Cockerel
Reactotype Part 3
At the end of the last post I realised I'd sacrificed some good practice in the rush to make it work (i.e. worked normally like all those other guilty software engineers everywhere everyday.)
So earlier today I played with the kids to tire them out enough that I could distract them with television and write some #holidaycode because I am a good(-ish) parent.
I managed to
- switch from using magic strings in the messagebus channel and topic identifiers
- remove some duplication
- and get some tests around ReactJS
Reactotype Part 2
I posted about my impressions of working with React slowly building an HTML table and banging on about it. I ended that post with one of the more memorable cliff-hangers in recent time.
Sorting and Filtering the Table
That we will leave till part two… because I introduced a relatively artifical constraint that I didn't want the filtering control to be a part of the table.
Imagine that there will be many tables with the same filter. I don't want to bind the filter to any one table or insist that every table has it.
At first I expected that it would force me to understand React's components and how to compose them… instead I stumbled on something really cool #cliffhanger
Exciting! Right?
I want to add a filter control and I don't want it to be bound to a particular table so that it can be re-used.
Reactotype Part 1
part one because I've got a feeling this is a topic about which I'll be able to bang on.
React JS was made by Facebook to be the V in MVC. In other words, it only deals with the UI. It's sold as being fast - both for performance and development. A contentious part of React is that it mushes JS and HTML together… More specifically, you put HTML inside the JS and not vice versa.