Generating static AMP pages
AMP or Accelerated Mobile Pages is a Google-backed project that allows you to use restricted HTML to delivery static content quickly. Since AMP HTML is restricted it isn't a fit for every site.
Since this blog is published as static HTML articles it is a good candidate for publishing an AMP version. An open source AMP jekyll plugin was amended to add AMP versions of pages.
The major discovery was that the validation tooling around AMP is awesome. Compare that to Facebook Instant Articles where there is basically no validation tooling (that I could discover at least)…
This didn't feel like a topic that justified several posts so to avoid taking too long this is a bit of a whistle-stop tour of adding AMP pages to this blog.
Yarn is a new JS package manager that promises to be fast, secure, and reliable. My initial experience is that it is fast and easy to use. 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
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.
Kill 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 just 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 just 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 blind 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
- kill 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
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 easily re-used.