When I look at nature I see a glimpse of the infinite creativity of our Father. Not only did He create every species, down to the seemingly endless variations of trees, brush, mammals, and insects, but He has seen every distinct movement of every creeping thing, down to the blood pulsing through their veins and the fur on their backs swaying in the wind. He has seen the way every single photon cast off from the sun makes contact with the trees, diffusing through their leaves, and touching down on the ground for all of history ad infinitum.

As I gaze at the sky, He gazes back. He is the light that makes contact with the photoreceptor cells in my eyes to reveal the majesty of creation. And every sunset that splashes across the sky, He has painted thoughtfully on an ever-shifting canvas. Yet to me, every day, in its own way, the sun sets more beautifully than I could possibly imagine. And in my limitation, every day is a mystery.

For modern man, travelling to another country typically offers no transcendent experience beyond drinking, eating, and taking the same photo of the Leaning Tower of Pisa that tens of millions of people have taken before you. This ritual is no different to me than if you just went to a local district themed after your culture of choice, and you ate at a restaurant where they spoke their native tongue to you, and then you step outside and stick your head through a photo stand-in and check off the photo in front of your attraction of choice. The only real difference is some abstract notion that you were in the correct geographic location, therefore you may now tick the country off your list. The article The age of average describes a creeping void of homogeneity using Airbnb and cafe interior design (see fig. 1 below) to illustrate how, all over the world, interior designers have unconsciously agreed upon a globally homogenous style-guide which affords well-to-do individuals the ability to travel to the other side of the world and see nothing new. Sure, you may go to a busy street market in Phnom Penh and see all sorts of people living drastically different lives to you, but at the end of the day you'll retire to a luxurious villa and forget all about the poverty surrounding you.

Figure 1: The age of average

Evola's Meditations on the Peaks captures this perfectly in the context of mountain climbing which had, in his view, been corrupted and trivialised as simply another vain pursuit of hedonism. "we cannot help but notice the presence among our young people, of love for risk and even of heroism. [...] mountain climbing, when experienced only in keeping with this view, would not be easily distinguished from the pursuit of emotions for their own sake". Evola continues, "This pursuit of radical sensations generates all kinds of extravagant and desperate feats and bold acrobatic activities [...] All things considered, these things do not differ very much from other excitements or drugs, the employment of which suggests the absence rather than the presence of a true sense of personality". To Evola, the spiritual majesty of the mountain from days of antiquity arose from their inaccessibility. Virtually all ancient civilisations situated around mountains saw the mountains as possessing some essence of immortality, as they conceived of the mountain as a separate plane of existence.

Technological advancements that make it easier to summit a mountain cheapen the experience. Now today, when virtually every mountain has been conquered, and we have helicopters and drone footage of the peaks, the mystery has been completely devoured by the machines of modernity. Consider the case of Tabletop Mountain in Toowoomba. In 2017 there was a proposal to build a cable car across from Picnic Point to the mountain. Tabletop Mountain is a tough but manageable climb for your average able-bodied person, but you still have to make a physical commitment to reach the top. Today, you can climb tabletop and find yourself completely alone, slightly closer to God, and able to look across the rolling hills at an ever-widening horizon. By making it accessible to everyone, you inevitably destroy what little mystique remains.

This brings us back to the "traveller" persona. I cannot blame, nor judge these people. After all, what spiritually transcendent activities can your average man really engage in today? The potential for enrichment has been sucked out of virtually every activity, and we are told there is no spiritual aspects to pursue within ourselves. You shouldn't have children because it's unaffordable, or because it's bad for the environment. You shouldn't pursue God, because that's for un-developed Neanderthals who haven't yet heard the gospel of Science. The only option presented to these people to achieve fulfilment is travelling, and it makes sense, because there is still a notion of triumph in travelling. You cross vast oceans in a matter of hours, whereas your ancestors - if they were even able to travel - would be crammed into the hull of a ship for weeks or months just to see one new country. Unfortunately for these people, when they make it overseas, they'll typically find many of the same trappings as they are accustomed to at home (see below for an image of an "English" street vandalised with American fast-food chains). In my own life, the last overseas travel I did was to Cambodia in 2018, and after I went to the Killing Fields and heard the harrowing tale, I returned to my hotel and on the same street was a Burger King and Cold Stone Creamery.

Figure 2: An "English" high street

The end result of all of this is the complete commoditisation of spirituality; a sort of drive-thru baptism where people are told that enrichment of the soul is yet another product to be consumed, rather than a lifelong pursuit within yourself. People are sold the idea that to be enriched, all you need to do is buy a ticket to see the sunrise at Angkor Wat and you'll be whole. Given enough time, I believe that even this level of spiritual enrichment is going to be made impossible for the average man (due to climate restrictions and the theft of their discretionary income by central banks) and travel may again be reserved for the social elite. Perhaps then our people will once again begin to look within.

Those who are irresistibly attracted to the mountains have often only experienced in an emotion a greatness that is beyond their understanding. They have not learned to master a new inner state emerging from the deepest recesses of their beings. Thus, they do not know why they seek increasingly wider horizons, freer skies, tougher peaks; or why, from peak to peak, from wall to wall, and from danger to danger, through their experiences they have become inexplicably disillusioned with everything that, in their ordinary lives, appeared to them as most lively, important, and exciting

Two men went up to the temple to pray, one a Pharisee and the other a tax collector. The Pharisee stood by himself and prayed: ‘God, I thank you that I am not like other people—robbers, evildoers, adulterers—or even like this tax collector. I fast twice a week and give a tenth of all I get.’ But the tax collector stood at a distance. He would not even look up to heaven, but beat his breast and said, ‘God, have mercy on me, a sinner.’ I tell you that this man, rather than the other, went home justified before God. For all those who exalt themselves will be humbled, and those who humble themselves will be exalted.

Luke 18:9-14

You must humble yourself. For all those who exalt themselves will be humbled, but the one who humbles himself will be exalted. Death is the ultimate sign of spiritual rebirth, and to die in the name of God would surely be the greatest honour a Christian can attain.

For my money, the crucifixion is the greatest form of humbling one could experience. Not only are you brutally executed and displayed as a warning to would-be "law"breakers, those who purport to be your brothers and sisters will rally around in Lemming-like obedience and celebrate your execution. After all, your fate has been determined by our god, the State.

For the Son of God to willingly humble himself to this degree, in the face of utter betrayal from his people, in the face of false accusations, who are you to have any pride in your insufficient self or your own abilities? If the time ever comes that we should choose our faith or death, Lord please give me the strength to choose You in the face of death. Father, into your hands I commit my spirit.

Amen.

This primer on Mencken's philosophy was quite profound, and, sadly, very underappreciated. I feel that this is an important perspective to re-frame the debate around statism versus a free society. The author shows that Mencken is not really a cynic, but a realist. As Mencken said, "Reconciling ourselves to the incurable swinishness of government, and to the inevitable stupidity and roguery of its agents, we discover that both stupidity and roguery are bearable - nay, that there is in them a certain assurance against something worse."

Indeed, his writings didn't bring about a free society - in fact, he correctly predicted that government would continue to grow at an exponential rate after his death. Advocating for the abolition of the state (or even the greater utopian vision of a limited state) is like trying to steer a cruise ship with an oar. So, how did Mencken work for a lifetime and still carry on with relative happiness? He didn't write to persuade. The author notes, "Writing to persuade can leave you with many peculiar stances. But writing to express your libertarian beliefs is a much more straightforward enterprise, and your writing is then relevant forever and won't come back to haunt you".

This makes me think of the modern Conservative whose current platform generally resembles the progressive platform of yesterday. It's an eternal game of rugby where the progressives charge ahead, and the conservatives celebrate a successful tackle without noticing they've ceded ground. When the progressives say, "we want $3 trillion in equitable infrastructure spending", if your response is to say "Let's compromise. How about $1.5 trillion?", you have already lost the debate. You tacitly admit that some government spending is good. If some government spending is good, then you obviously can't have too much of a good thing, so why stop at $1.5tn?. You are attempting to persuade the progressive to your position that government spending is evil by agreeing to government spending. Instead, you should argue from the principle that all government spending is necessarily funded by theft at gunpoint and therefore any concession is unconscionable.

Conservatism in 2021

The book has shown me that I have been far too utopian in discussions about free societies. Rather than listing all the ways that a free society will be better for the individuals within it - given that this is entirely subjective, (and many people find a great deal of comfort in being subordinate to the coercive monopoly of the state) - it is far more productive to argue from first principles. You may not be liked, but you will be authentic, and that is far more important in the long term. No amount of concession from you will make a free society any more likely. You'll either be hated for adhering to your principles, or you'll be forgotten because you abandoned them.

"The fraud of democracy, I contend, is more amusing than any other... All its axioms resolve themselves into thundering paradoxes, many amounting to downright contradictions in terms. The mob is competent to rule the rest of us - but it must be rigorously policed itself. There is a government, not of men, but of laws - but men are set upon benches to decide finally what the law is and may be [...] I confess, for my part, that it greatly delights me. I enjoy democracy immensely. It is incomparably idiotic, and hence incomparably amusing."

H. L. Mencken

The book is very entertaining, and it's a very easy read (took me probably 5 hours, and I'm a particularly slow reader). I went through with a highlighter and emphasised the key points, but I found that as I got to the middle of the book, the insights started to dry up. As I got to Chapter 8 (A rebublic is born), it started to drag. I suspect - though I may be wrong - that this is approximately where the original allegory of Able, Baker, and Charlie growing the economy ended, and where the younger Schiff's original portion began. It was still entertaining, but unlike the start which was packed with easy to understand explanations for economic principles, the middle part leading up to the housing crisis was mostly a rushed re-telling of history with a healthy helping of fish puns.

When the authors got past the historical portion and into the future, the book did read better, and it ended very strongly. As this book came out in 2010, the authors envisioned a future where America had to face the music, and Obama took responsibility for his economic policy blunders. Unfortunately, with hindsight, we know that sort of happy ending is rare in politics. Obama and the Fed's policies became worse, which Trump then inherited, and continued. Ten years after publish, the crash described in the book hasn't arrived as the authors expected, but given the state of the American economy it seems more likely by the year.

Here's some key takeaways from the book:

Demand and consumption do not equate to economic growth

(After increasing the productive capacity of the island; that is, catching more fish) "This didn't happen because the three guys were unsatisfied with their limited lifestyle. Their hunger, which is labeled "demand" in economic terms, was necessary to spur economic growth but not sufficient to achieve it."

"With their extra fish, the islanders can finally eat more than one fish per day. But the economy didn't grow because they consumed more. They consumed more because the economy grew."

Denying loans with no pay-off

(About Able giving a loan to someone to take a holiday) "Not only would such a transaction put his savings at unnecessary risk, but it would mean that the capital would be unavailable for more productive loans."

"In actuality, loans to consumers that do not fundamentally improve productive capacity are a burden to both the lenders and the borrowers."

Falling prices are good for everyone

"Steadily dropping prices also encourage savings as islanders begin to understand that their fish would likely buy more goods in the future than they do in the present."

Keynesians react to falling prices like a vampire reacts to a crucifix. Such a reaction is understandable when you realise that their theories are predicated on the idea that spending (i.e. consumption) equates to economic growth. This is why their primary course of action when faced with an economic contraction is monetary stimulus. Inflation is the best way to ensure people spend what they make, because if people know prices are going to rise, they are more likely to spend their money on goods they'll need in the future.

I'd suggest this book for people with a cursory interest in economics but without much of a background. It's quite easy to grasp and would be good for young high school students.

I give it a 6/10.

When priced in gold, you can see that over the last hundred years (see the graph below), the US Dollar has lost all of its value. The graph below plots the price of gold per ounce against the USD from 1915 to present. In 1915 the price of an ounce of gold was $19.25. When the dollar was created in 1792, the cost of gold was $18.60 per ounce, which we will refer to as the baseline value of the dollar. Between 1792 and 1915 (123 years) the price of gold only increased by 65 cents (roughly half a cent per year in inflation or an average of 0.028% p.a.). During this period, wages were relatively flat, however, America also became heavily industrialised, and the cost of living reduced by half. So, not only did the value of your money remain flat, you were able to buy more goods.

You'll note that the price of gold was flat until ~1932 when the government decided that it needed to devalue the currency, so it could create more dollars (since they were on a gold standard, they could only have as many dollars as you had gold reserves), so the legislature re-defined the value of an ounce of gold to be $35. Back then, it was a simple change of definition, since the dollar was still tied to, and redeemable in gold and silver. You'll notice that all hell breaks loose in 1971 when America left the gold standard (duping the entire world into accepting fake money tied to no real world value for their exports), and people were no longer allowed to redeem gold for their dollars (including foreign investors). Between 1971 and today, the price of gold rose from $36.56 to $1715.24 (as of March 2021). That is a face-melting 4591.56% inflation rate in 50 years, or an average of 91.8% per year.

The graph begins shortly after 1913 when the Federal Reserve Act was passed (creating the Federal Reserve), and the Sixteenth Amendment was ratified (allowing for the government to tax income). The Federal Reserve was intended to be an apolitical, non-government organisation to allow the creation of money to be separate from the legislature. That seems ridiculous in hindsight today, as the Fed and the legislature are just two sides of the same spending-addicted coin, hell-bent on debasing the currency no matter the cost. This isn't anything new; the Fed has been monetising the government's debt since the inception, but I think the wheels came off when legislature made the decision to leave the gold standard to fund their war machine abroad. The few checks and balances that previously existed evaporated. Before the legislature could vote to devalue the dollar, allowing the Fed to print more money, but after leaving the gold standard, the Fed now digitally prints tens of billions of dollars per month to buy treasury bonds to fuel the stock market bubble. Similarly, the income tax was another ill-fated policy. Originally, the income tax rate was 1% for people earning $0 to $20,000 (which is ~$529,911 today, according to the CPI, or $1,782,067 when priced in gold) with a top nominal tax rate of 7%. Clearly, in hindsight, these low rates were the camel's nose under the tent, and this was the government laying the groundwork for massive tax hikes during World War I (yet another war America didn't need to be involved in). By 1918, the top nominal tax rate was a whopping 77%.

All of that background is just to highlight the state of decay America is in which continues to accelerate as government grows. The reason I like to view inflation through the lens of gold price is because gold has been used as money for thousands of years, which is a much more meaningful time-scale than the ~240 years the USD has been in existence. Interestingly, when you price the Dow Jones index in dollars, it's at a record high of $32,981.55 (compared to the $1457.37 in 1915), which is an increase of 2163%, however, when you price it in ounces of gold, today it's at 19.23Oz (as compared to the 2.86Oz in 1915), that's an increase of 572.4%. A far cry from the >2,000% when measured in dollars.

Now that you're caught up on the historical horrors of the US dollar, we can talk about the present horrors. 40% of all dollars in existence were printed in 2020, and already in 2021 there has been nearly half a trillion dollars added to the national debt. The CPI is the measure of inflation we typically use (which is actively manipulated to understate the true increase in goods prices), and in March 2021 alone, it measured a 2.6% increase. It is no longer a conversation of "massive inflation is coming". Massive inflation is HERE! Look at the price of lumber for example (see below), which has had a 47% increase so far this year, after a 125% increase last year.

It should be clear from the preceding rant that I believe gold is the best way to hedge yourself against inflation, especially since, unlike wheat and oil, it never decays. Remember, it's not that gold is getting more expensive, it's that the dollar is getting weaker. So, trading precious metals for commodities to hedge yourself against currency fluctuations is the best course of action. What should you do if you don't have the available capital to buy gold? Firstly, you can buy much larger quantities of silver for far lower prices than you can buy gold, and it's more viable for everyday exchanges because it's more divisible.

Assuming you can't buy silver either, you should not let your money wither away at 0% interest in the bank or risk losing it on overpriced stocks (I'm not advising you pull your retirement funds out of the market, but you could consider mixing in some inflation hedges like gold and gold mining stocks). The best thing you can do locally is stock up on goods that you know you will need down the road. In 2017 Mark Cuban (Newly converted Bitcoin bull) said that people struggling to get ahead should buy in bulk and on sale. In hindsight, this was fairly prophetic considering where we are today. Many goods on the shelves are experiencing unprecedented price surges, and that doesn't even address the real possibility of serious goods shortages in the near future. Start working out how much of each non-perishable good you use per month and extrapolate that for a year. Here are some ideas for you:

Toilet paper

If you use 4 rolls a month, that works out to 48 per year. Buy four 24 packs and you are set for two years without buying toilet paper. Make sure you store it in a cool, dry place.

Laundry detergent

This is rather self-explanatory, but you should be wary that powdered detergent only has a shelf life of 6 months, so consider using liquid detergent.

Toothpaste

Colgate recommends a maximum of two years shelf life, so don't buy too much

Other examples

You can really go hell for leather with this, just consider if you have the right conditions in your house to store them long term.

• Toothbrushes
• Tissues (or switch to washable cloth handkerchiefs)
• Dehydrated meals
• First aid supplies
• Powdered milk

If you are curious about getting started buying precious metals, check out Schiff Gold for Americans, and Perth Mint or ABC Bullion for Australians. If you are worried about inflation, you should steer clear of buying gold/silver ETFs as you don't have the security of physical metal, and it can be easily seized by the government. With a gold broker like the above, you can store it at their secure facilities and request redemption at any time. I don't keep any physical metals as I don't have anywhere to securely store it, but a bank safe deposit box would be a good alternative.

Good luck out there everyone.

• the build process has always been dodgy for me,

• the watch (i.e. gatsby start) failed after being up for a while

• builds didn't work on Windows Linux Subsystem

• overburdened with configuration modules

  

  The Lighthouse audit results after my first round of changes
  

The biggest selling point for me is the getStaticPaths function in the Next.js pages. Before, as a pre-build step, I was generating the entire page tree of React components using a node script. Super heavy handed, and I'm sure there's better ways to do it in Gatsby. What I'm doing now looks like this:

.
└── pages
    └── blog-posts
        └── [year]
            └── [month]
                └── [title].tsx

The resulting output is visible in the address bar in your browser. Blog posts routes look like: /blog-posts/2020/08/some-name

[title.tsx]

export function Post() {}

export async function getStaticPaths() {
    const blogPosts = await getBlogPosts();

    const paths = blogPosts.map(
        post => `/blog-posts/${post.year}/${post.month}/${post.title}`
    );

    return { paths, fallback: false };
}

In the getStaticPaths function you return a list of new paths and Next.js automatically spits those pages out. At build time, you can then use the path parameters to fetch external data and build your components. What this means, in effect, is that your /pages folder no longer maps 1:1 to the static output. So you can't just build a sitemap off the page directory anymore.

There's a comprehensive article on the topic by Lee Robinson (https://leerob.io/blog/nextjs-sitemap-robots) but this guide also assumes your source pages are 1:1 with the expected output. I adapted his script to build based off the folder output instead.

1. Download required dependencies (square brackets denote optional dependencies)

yarn add -D glob [chalk] [prettier]

2. Create sitemap script

import glob from 'glob';
import fs from 'fs';
import { red } from 'chalk';
import prettier from 'prettier';
import prettierConfig from './.prettierrc.js';

(() => {
    // default next js output is `out`
    // all the pages are guaranteed to be html
    glob('./out/**/*.html', (err, files) => {
        // If there's no files in the output, a build probably hasn't been run
        if (!files.length) {
            console.error(red('Could not find output directory'));
            process.exit(1);
        }

        const sitemap = `
        <?xml version="1.0" encoding="UTF-8"?>
        <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
            ${files
                .map(page => {
                    const path = page.replace('./out', '').replace('.html', '');
                    const route = path === '/index' ? '/' : path;

                    return `
                        <url>
                            <loc>${`https://{Your Domain Here}${route}/`}</loc>
                            <changefreq>daily</changefreq>
                            <priority>0.7</priority>
                        </url>
                    `;
                })
                .join('\n')}
        </urlset>
    `;

        // Optional: you can remove this block if you aren't using prettier
        const formatted = prettier.format(sitemap, {
            ...prettierConfig,
            parser: 'html'
        });

        fs.writeFileSync('./out/sitemap.xml', formatted);
    });
})();

3. Add script to package.json

{
    "scripts": {
        "start": "next start",
        "build": "next build && yarn run build:sitemap",
        "build:sitemap": "node ./generate-sitemap.js"
    },
    "devDependencies": {
        "chalk": "^4.1.0",
        "fs-extra": "^6.0.1",
        "glob": "^7.1.3",
        "prettier": "^1.18.2"
    }
}

That's pretty much it for my implementation. You can see my sitemap here https://lukeboyle.com/sitemap.xml.

I realise that this is one of the most well-explored topics on the privacy-conscious edges of the internet, but seriously... Do not trust Google. Facebook seems to be our current punching bag of choice because of their supposed ability to manipulate political opinion, but in my opinion Google is a much more insidious company with far greater potential for abuse. Google is the largest advertising platform by a significant margin (accounting for 36.3% of advertising in the U.S. with Facebook trailing at 19.3%). At the end of the day, if you delete your Facebook account, what are you really missing out on?

Google (or more specifically Alphabet Inc.) owns the largest search engine (Google.com), the largest video streaming platform (Youtube), and the most-used smartphone operating system (Android). You might ask, "What's wrong with that? Sounds like they're just very successful at what they do". Well, let's break down those three markets (Search, Streaming, Mobile).

Search

Google's estimated market share for search traffic globally is 92.16% source. As people increasingly are using search to navigate the web (as opposed to typing a URL into the address bar), this traffic increases, those people see more ads, Google makes more money. Google then uses this money to purchase exclusivity agreements with the likes of Apple (just two years ago it was announce that Google would be paying $12 billion US to Apple to remain the default search engine on Safari in 2019 source at a cost of roughly $10 per user).

How does Google abuse Search?

If you ask the average user how Google search works, they'd probably say "it just searches for your search term across the web", but what they probably don't know is that is just the tip of the iceberg. Other dimensions of search include:

• what kind of users go to that websites (and does the user searching fit that profile)?
• how much traffic does the website get?
• how relevant the content is to the search term (SEO magic)?
• and, most importantly, does this website fit an acceptable narrative?

There's certainly an argument to be made for suppressing some search results, such as pro-authoritarian sites (e.g. communist or fascist), extremely fringe conspiracy, illegal pornography, or bomb-making instructions. Advertisers probably don't want their ads next to those results. Rightly or wrongly, Google is already suppressing content from such websites (though, they're probably still indexing them).

If Google can suppress fascist content from sites like Stormfront (prominent white-supremacy forum), then who is to say which content they can or cannot suppress? Breitbart is a well-known right wing news site that has had their content almost entirely purged from Google search results (as evidenced by the "search engine visibility" chart below).

You don't have to agree with them politically to see that Google is applying different standards to conservative content than to more liberal content. I don't visit Breitbart, I don't read their articles, and frankly I don't give a shit what they have to say, but I believe in a free and open internet. If you believe in a free and open internet then you have to agree this is wrong. During the cold war, anyone who didn't follow the extreme protectionist beliefs of the time were shouted down as communists (Even Martin Luther King Jr. was dismissed as a communist by J. Edgar Hoover). This same thing is happening now, but the buzz word is different. The new weaponised word is "Nazi". If time had elapsed differently, I have no doubt that it would be left-wing websites suppressed in search results, and that still wouldn't be okay.

There's plenty of evidence to suggest that Google is manually making these decisions to block conservative websites, however, Alphabet CEO Sundar Pichai denied that they manually censor websites at the recent Congressional antitrust hearing except for in cases where there are legal requirements or copyright issues. I don't buy that, personally.

Streaming

When YouTube was founded it was facing severe scaling problems (because video processing and streaming is extremely expensive). Fortunately for them, Google saw potential in the platform and purchased the company for $1.65bn in Google stock, and their money issues were over. Google was throwing money into scaling the platform, and it was experiencing great growth. This success turned out to be a major problem for the YouTube, because, from the time it was purchased it has been making a loss. In recent years, YouTube has become profitable, however, without the bottomless pockets of Google behind it, they never would have been able to accomplish this. What incentive could Google have to take losses year after year on YouTube? Well, it turns out user data is particularly delicious. Mastercard's CEO has infamously said "data is the new oil". I personally can't wait for Facebook, Amazon, and Google to become para-military organisations in the up-coming data wars.

YouTube has essentially bullied their way into market dominance using Google's bottomless pit of money. This is problematic because it allows failing companies to cheat death. Just like a bottom-feeding fish,latching onto a whale shark and hitching a ride. As I mentioned before, video streaming is extremely expensive, so it makes sense that great cloud infrastructure is a prerequisite to success. Well, big surprise, Google offers world-class commercial cloud infrastructure with Google Cloud Platform (GCP)! Do you suppose YouTube is paying full price for their infra?

So, when you see a headline that says "Stop paying for iCloud – Google One will now back up your iPhone for free". Before obeying the shill who wrote it, you should ask yourself, "How can a company afford to give away so much storage space for free?". Well, they can't. Google simply obscures their losses with the immense revenue from Google Ads in the profit/loss statement at the end of each quarter. For more reading about this topic, Tim Bray has a fantastic article called "Break up Google".

Mobile

This article is already becoming too long, so I'm just going to cover mobile quickly. As Tim Bray mentions in the article above, Android isn't really a business. The only real non-ad revenue they have is from the commission they get from app purchases and licensing fees from OEMs (e.g. Samsung, Huawei, LG). How, then, are they able to sustain hundreds of highly paid engineers and all the other non-technical staff required to support the system?

Above is a map of Android vs iOS market shares. You can see that iOS pretty much only has the dominant market share in first world countries (like USA, Canada, Australia, UK, Japan). Most of the emerging countries in the world are strongly in favour of Android because, unlike Apple, the OS is not restricted to a particular device. So, countries like India (where the number of smart-phone users has increased sharply from 199 million in 2015 to 401 million in 2020 source) that mostly purchase low-cost phones (e.g. Huawei, Xiaomi, Oppo). Emerging markets are extremely important to companies like Google partly because these countries are easier to exploit because they don't have strong legislation to protect users from predatory advertising, anticompetitive tactics, or data privacy. This is why I speculate that Mastercard is scrambling to connect refugees to the global payment network (Remember that quote from the Mastercard CEO: "Data is the new oil") and, indeed, why Mastercard forced Patreon to ban Robert Spencer for his anti-refugee sentiment.

Again, regardless of whether you agree with someone's political leaning or rhetoric, I shouldn't have to explain why it's ludicrous for people to believe that faceless, soulless corporations such as MasterCard or Google give two fucks about moral righteousness when their only servant is a number ticker on the Nasdaq website.

Closing thoughts

So, after reading all of that, I have to ask:

Why don't you route all of your web traffic through Google Servers?

To be clear, I'm not accusing Google of storing DNS logs or associating that with specific users (they claim that they don't in their terms of service), however, I think it's unreasonable to think that they wouldn't be capable of that. I also wouldn't put it past them to lie in terms of service considering their recent run-ins with the law ($1.7bn fine for anti-competitive behaviour, $170m for violating children's privacy on YouTube, 50 million euro fine for GDPR violations).

$2bn doesn't matter to Google. It's a drop in the bucket, especially considering they would probably be able to freely harvest user data for months or even years before they're caught and slapped on the wrist. If a single user's search data is worth upwards of $10 a year (see the Safari Google default search engine deal) for Google, then the complete logs of their browsing history would be quite juicy indeed.

Okay, so that's verging on conspiracy theory I suppose. Maybe Google DNS will remain clean. How about you get a Google® Nest™ WiFi mesh router and let them inspect all of your web traffic that way?

Or perhaps you want to buy the new Pixel and give them advanced analytics about how you use your phone (privacy class action lawsuit), everywhere you go (Location History), how much physical activity you do (Google Fit), every article/video you engage with (Chrome), everything you buy (Google Pay - and incidentally, how much disposable income you have, so they can better target more relevant ads to you). All of these "services" are simply a ruse so that Google can build an extremely accurate profile about the type of consumer you are and target you with more advertising to turn you into a soulless consumer.

I don't want these people to also be the arbiters of what content I should or should not be able to see online.

Actual closing thoughts

Well that was pretty depressing. So, how can you reclaim a shred of your privacy?

Search

There's a swathe of privacy-focused alternatives popping up these days. I personally use duckduckgo.com which is built on the Bing search API and does not track any user data. I'll concede that Duckduckgo doesn't have as good search results, but I'm okay with that. Another one is https://www.startpage.com/ which actually uses Google results, but ensures Google can't track your activity.

Streaming

I'm currently using invidio.us which, like Startpage, is just a wrapper for YouTube. So you can get the same content minus the tracking. Bonus, check out Invidition on the mozilla extension store to open all youtube links in invidio.us instead.

Mobile

I really don't have an answer for this one. I'm an iPhone user, but really, Apple is not much better, especially if you care about having a repairable device. If you really want to go hardcore there's some custom Android forks like https://grapheneos.org/

Browsing

I didn't really touch on Chrome, but I'm not happy with Chrome either. Since Edge has switched to using Chromium the only real competitor (i.e. non-Chromium) in the browser market share is Safari. I use Firefox because I believe in Mozilla and their commitment to maintaining privacy. They're doing good stuff lately.

Before

Back Squat

95kg x 3

Overhead press

67.5kg x 1

Farmer Carry

140kg (15 meters) x 2)

Bench Press

80kg x 5

Deadlift / Deficit Deadlift

125kg x 5

Pendlay Row

70kg x 5

Pull up

BW(115.7kg)x3

Trap bar deadlift

145kg x 1

After

Back Squat

115kg x 2 +16.35% 1RM

Overhead press

80kg x 2 +24.4% 1RM

Farmer Carry

168kg for 15 meters x 2 - +20.4% 1RM

Bench Press

110kg x 1 - +18.3%

Deadlift / Deficit Deadlift

165kg x 2 - +18.5%

Pendlay Row

85kg x 4 - +17.1%

Pull up

BW(122kg)x2

Trap bar deadlift

180kg x 3 - +35.2%

So how did I "increase my 1RM by 18-35%"? One simple trick! "Adherence" (and maybe a bit of residual newbie gains).

Adherence before OLAD

Adherence after OLAD

I really just owe this adherence to the renewed enjoyment I've had in the gym. It's pretty great to get out of the gym within 45 minutes (excluding prehab/rehab). I was quite fatigued by the few cycles of 5/3/1 I had just done (not to mention the 1.5 hour workouts), so it made sense I was burned out.

All things considered, I'm really happy with this program. After my second knee dislocation in 2019 I didn't expect to be squatting again but here we are. It's not the most encouraging sign when your bench is beating your squat, but I'm not giving up.

Lifts

Strict overhead press - 80kg (~176 pounds) x 2

Trap bar deadlift - 180kg(~396 pounds) x 3

Squat

I have no recent squat footage so here's some of this weird reverse safety bar front squat thing I got from John Meadows

Bench - 105kg(~230 pounds) x 2

My progress plateau might suggest that this experiment was a failure, however, it has made the gym far more enjoyable than cranking out the same repetitive workout week in and week out. I also noticed that I end up spending far more time on the core exercise and often won't add any accessories. Workouts are overall shorter and more satisfying. I've also been able to rotate in more variations (e.g. push press, pin press,safety bar squats, deficit deadlifts) which helps with lift boredom. The next logical step from here would be to make my workouts more consistent and strategic.

The One Lift a Day (OLAD) system has gained more popularity in recent years. Eric Bugenhagen has been championing OLAD for years and Alec Enkiri recently broke down his OLAD program. Given his insane strength and general athleticism (585lb deadlift, 4.5 second 40, 60" box jumps) it's always interesting to see how his programs reflect that. I challenge you to find a cookie cutter program that includes resisted sprints. The exercise selection with OLAD is entirely up to you and should be based on your goals, but Alec suggests including a squat, hip hinge, loaded carry, horizontal press, vertical press, upper body pull.

For rep schemes and progression I turned to Dan John's one lift a day program This program is built on 4 week cycles like so:

• Week 1: 7 sets of 5
• Week 2: 6 sets of 3
• Week 3: 5/3/2
• Week 4: Off

I'm going to be doing this program for 3 months (i.e. 3 of these 4 week cycles). My exercises (with a recent set in brackets):

• Monday: Back Squat (95kg x 3)
• Tuesday: Push Press (no recent sets)
• Wednesday: Farmer Carry (140kg for 15 meters x 2)
• Thursday: Bench Press (80kg x 5)
• Friday: Deadlift / Deficit Deadlift (no recent sets)
• Saturday: Pendlay Row (70kg x 5)

I'll be documenting progress for the next 3 months and we'll see if the gains gods bless me.

It has been a couple years since Gitlab's rise to prominence and the market has certainly shifted. Even before Github was acquired by Microsoft in Mid 2018 (source), they were hard at work pushing out feature after feature.

Off the top of my head, I can recall these:

• Projects (Kanban boards with automated status changes)
• Sponsor program
• Package Registry (publishing for npm, NuGet, Ruby gems, all in the same platform)
• Github Actions (my personal favourite)

Github actions is now in open beta (you can opt in here: https://github.com/features/actions) and it enables you to set up containerised builds, testing, deployments in response to many github events (push, pull requests, tags, schedule).

The process is much the same as something like CircleCI, Travis, or Buildkite. The integration for CI checks on pull requests and commits has been in Github for years, allowing early warning for pull requests that break the build.

In this post I'll be showing you how to set up to build and release a single-page app running React.

Keep in mind that the v1 Github Actions syntax has been deprecated, so make sure you are looking at the yaml documentation. There's a handy warning at the top of the deprecated pages:

The documentation at https://developer.github.com/actions and support for the HCL syntax in GitHub Actions will be deprecated on September 30, 2019. Documentation for the new limited public beta using the YAML syntax is available on https://help.github.com.

Find the docs here: https://help.github.com/en/categories/automating-your-workflow-with-github-actions

For this example, I'll be using Create React App. Initialise that if you'd like to follow along, or just retrofit an old, simple project.

There's two flows I want to create

• CI Only
• CI and Deploy

Let's create the action file.

Create a folder in the root of your repo .github/workflows Create a file in that folder called ci.yml

Let's look at the ci.yml file and add some boilerplate

ci.yml

name: CI

on: [pull_request, push]

jobs:
    build:
        runs-on: ubuntu-18.04

        steps:
            - uses: actions/checkout@master
            - name: Use Node.js 10.x
              uses: actions/setup-node@v1
              with:
                  version: 10.x
            - name: Build
              run: |
                  npm install
                  npm run build --if-present

The first thing to note is on line 3, there is an option called on (docs for on. This field is a list of signals you want to respond to. For this one, I'm only doing it on pull request. Because this on property is at the top level, regrettably you can't combine all your steps and choose not to run some steps on pull request. This is the reason for having two separate action files. In principle, the actions should be entirely self contained processes.

The jobs is a list of independent actions. By default, they run in parallel. You could use this to separate things like your unit and integration tests to speed up your CI. This example is pretty simple, so I haven't found a use for the jobs yet.

The steps field is quite simple in this example. For each step, you can chose to specify the uses field (docs). The format for this argument is [owner]/[repo]@[ref] or [owner]/[repo]/[path]@[ref].. You can reference actions in your current repository or you can reference standard actions as per the example above. actions/checkout@master checks out the current branch. actions/setup-node@v1 sets up Node, probably through a Docker container. You can provide arguments to the action using the with key.

Now, the magic begins. Go to your repository and visit: https://github.com/[yourName]/[yourRepo]/actions. You'll be prompted to enable Actions for this repository. Hit enable and then commit your ci.yml file, push it up and check the Actions tab. You should begin to see your commits start popping up under the relevant action.

In the image below, you can see the left side has the name of the action, the event that triggers it, and the jobs below that.

With luck, we now have our CI build successfully running. Onto the deployment action. Copy the below to your ci.yml

ci.yml

name: CI

on:
    pull_request:
    push:
        branches:
            - master

jobs:
    build:
        runs-on: ubuntu-18.04

        steps:
            - uses: actions/checkout@master
            - name: Use Node.js 10.x
              uses: actions/setup-node@v1
              with:
                  version: 10.x
            - name: Build
              run: |
                  npm install
                  npm run build --if-present
            - name: Deploy
              if: github.event_name == 'push' && github.ref == refs/heads/master
              env:
                  AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
                  AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET }}
              run: node scripts/deploy.js

You'll note that at the moment we're executing this on both:

• pushes to master branch
• pull requests

This means that unless we add a filter, we'd be deploying branches on any pull request, which could probably break our app.

To the Deploy step, we've added an if. This if should have a boolean value that will determine whether to run the step or not.

You could do things like check if a step was successful, or in our case:

• Make sure the event is a push
• Make sure the branch is master

Moving onto deployment, if you look at the env key, this is how we provide environment variables to the step. These are accessible in node scripts via process.env. SOME_API_KEY in this example is a hardcoded string. Github also provides a secrets manager within your repository. Don't worry about that node script yet.

At a previous job, they outlawed all external CI services because they were worried about their AWS IAM keys getting out in the event of a CircleCI data breach. Given that we're dealing with Github + MSoft, I have to believe there's some encryption magic happening when you upload and access these secrets. Once you've set the value in the secrets, you will not be able to see it again and it will only be exposed to the CI agent.

I tried to log one of these secrets, and cleverly, it was censored in the logs (see below). Gone are the days of having to rotate your IAM keys because you accidentally logged it in your CI or Cloudwatch.

I'll come back to those AWS secrets shortly. From this point, all we have to do is deploy. I'm going to offer three suggestions:

• AWS S3 static web hosting
• Github pages
• Now.sh Tutorial coming soon

I would argue that S3 is superior to Github Pages. The unfortunate part of Pages is that it can only serve from files in the repository, so you have to commit your built files in order to host. However, Pages are free forever, unlike S3 sites which will begin to cost if you start having significant traffic. If performance is a concern for you, look elsewhere as neither of these are going to be blazing fast.

I'd suggest going with Github pages for simplicity as you'll avoid setting up an additional account (and potentially save $$).

Most sites I make are not under high demand, nor do they have many concurrent users, so for my purposes, S3 storage is more than enough.

I also use Cloudflare to cache the assets, so the majority of sessions download assets off the Cloudflare CDN, rather than S3, so my usage stays very low for S3. This also has the benefit of using Cloudflare's smart routing to make my Sydney hosted S3 bucket much faster for international users.

S3 Deployment

See the example repository here: https://github.com/3stacks/github-actions-react-s3

First I'll quickly go through how to get your S3 bucket and IAM keys and be a bit responsible in the process.

Create the bucket

• Go to your AWS panel and navigate to S3.
• Click Create Bucket and give it a url friendly name the same as the domain you will use for.
• Choose whatever region is most appropriate for you. I chose Sydney (ap-southeast-2) because most of my traffic is Australian
• Skip step 2
• On step 3, untick the Block all public access checkbox
• Visit your bucket, go to Permissions, then to Bucket Policy and paste the below in (replacing the arn)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::your-arn-here/*"
        }
    ]
}

With this policy, any user that queries can get any object in the bucket, so please, don't store anything private in there.

• In Properties, go to Static web hosting
• check "Use this bucket to host a website"
• make the index document index.html
• your endpoint will be displayed there

Creating the IAM user

We're going to start by making a policy that is our deployment policy for this bucket. It ensures that if the keys to an IAM user leak all you'll be giving away is access to that single bucket.

• Go to IAM
• Go to Policies on the left
• Change tabs to the JSON editor, rather than the Visual Editor
• Paste in the follow, replacing the ARN with your own bucket's ARN
• Name your policy. I called mine [projectName]DeployPolicy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::your-arn-here.io"
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": ["s3:PutObject", "s3:GetObject", "s3:DeleteObject"],
            "Resource": "arn:aws:s3:::your-arn-here.io/*"
        }
    ]
}

• On the left, navigate to Users
• Create a User
• Give it a relevant name ([projectName]DeployUser?), tick Programmatic Access
• Select Attach existing policies directly
• Search for your newly created policy and attach it to the user
• Click through the wizard
• Take note of your Access Key ID and Secret access key

Storing and using the secrets

• Visit https://github.com/3stacks/[yourProject]/settings/secrets
• Click 'Add a new secret'
• Call it AWS_ACCESS_KEY_ID and copy the corresponding value from your newly created IAM user
• Repeat for AWS_SECRET

Now your Github Action will pick these up in ci.yml. Copy the contents of the deployment script from here: https://github.com/3stacks/github-actions-react-s3/blob/master/scripts/deploy.js to a directory (./scripts/ is what was defined in ci.yml, but you can change this if you prefer a different directory). Make sure you update the S3 bucket name on line 24.

Your ci.yml workflow should resemble the below:

ci.yml

name: CI

on:
    pull_request:
    push:
        branches:
            - master

jobs:
    build:
        runs-on: ubuntu-18.04

        steps:
            - uses: actions/checkout@master
            - name: Use Node.js 10.x
              uses: actions/setup-node@v1
              with:
                  version: 10.x
            - name: Build
              run: |
                  npm install
                  npm run build --if-present
            - name: Deploy
              if: github.event_name == 'push' && github.ref == 'refs/heads/master'
              env:
                  AWS_DEFAULT_REGION: ap-southeast-2
                  AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
                  AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET }}
              run: node ./scripts/deploy.js

Ensure you set the region you would prefer in the deploy env.

Now we're done! Commit those changes, push it and you'll see the build run and deploy your app.

Visit http://[bucketName].s3-website-ap-southeast-2.amazonaws.com/ to verify.

From now on, commit on master and your code will be deployed automatically.

Github pages deployment

See the example repository here: https://github.com/3stacks/github-actions-react-pages

Visit https://github.com/[yourName]/[yourRepo]/settings and scroll to the Github Pages section. Here you may enable github pages on the master branch or gh-pages, root folder (i.e. you build into root directory) or master branch /docs. I prefer to use a separate branch as it's generally advisable to keep your master branch clean of build files.

To enable the gh-pages branch, the repo must already have one. In your terminal, do the following:

git checkout -B gh-pages
git push origin gh-pages

Back in your browser, select the gh-pages branch in the Pages dropdown (See below):

From here, deployment is fairly painless. Let's take advantage of the Actions ecosystem Github is building and use: https://github.com/marketplace/actions/deploy-to-github-pages?version=1.1.2, an action written by James Ives.

First we have to generate a personal access token.

• Go to https://github.com/settings/tokens

• Click Generate new token

• Select the appropriate scopes. We only need repo related scopes (below)

• Do not share this key with anyone. It has access read/write access all your repositories *

Add the secret as per the Storing and using the secrets section above, calling your access token secret GITHUB_ACCESS_TOKEN

Back in ci.yml,

name: CI

on:
    pull_request:
    push:
        branches:
            - master

jobs:
    build:
        runs-on: ubuntu-18.04

        steps:
            - uses: actions/checkout@master
            - name: Use Node.js 10.x
              uses: actions/setup-node@v1
              with:
                  version: 10.x
            - name: Build
              run: |
                  npm install
                  npm run build --if-present
            - name: Deploy to GitHub Pages
              uses: JamesIves/github-pages-deploy-action@1.1.3
              if: github.event_name == 'push' && github.ref == 'refs/heads/master'
              env:
                  ACCESS_TOKEN: ${{ secrets.GITHUB_ACCESS_TOKEN }}
                  BRANCH: gh-pages
                  FOLDER: build

Our secret and other required arguments will be provided to the Pages Deploy action using the env key.

If you aren't using a custom domain

Due to the way the routing is done in github pages, assets referencing / will go to the root of your Pages (e.g. https://3stacks.github.io). This means none of the assets in CRA will be loaded. To get around this, in your package.json, add "homepage": ".",. This will make it resolve correctly.

Now we're done! Commit those changes, push it and you'll see the build run and deploy your app.

Visit http://[yourName].github.io/[repo-name] to verify.

From now on, commit on master and your code will be deployed automatically.

Now.sh deployment

COMING SOON - This section is not complete

Tidbits

Containerised Steps

Github Actions also supports using specific Docker containers from Dockerhub. So if you have complicated dependencies, you can choose to utilise this option. Use the uses key and give it a path in the format of: docker://[image]:[tag]

https://help.github.com/en/articles/configuring-a-workflow#referencing-a-container-on-docker-hub)

YNAB (You Need A Budget)

YNAB is a very interesting take on budgeting. I used to swear by my old way of using a spreadsheet, but it sort of falls apart when your pay is irregular (like for self-employed people or freelancers with variable income). You can connect your bank accounts for automatic transaction feeds but I prefer doing it manually as it seems to make you more mindful about your spending.

Reporting

I'm a real metric head, so I appreciate some good graphs.

Age of money

Age of money tells you how long between getting paid do you spend your money. It's very encouraging to see yourself breaking the cycle of pay-cheque to pay-cheque.

Net worth

Net worth is pretty self explanatory. It tracks your assets versus your debts and gives you a nice net worth graph over time.

Spending

You also get a categorical breakdown of your spending which you can click into to see more specific information about each category

Free budgeting resources

The bulk of their blog posts are not YNAB specific, but include general advice for budgeting, so if you're struggling, it may be helpful for you.

If that sounds appealing, there's a link below which includes a referral (if you sign up I get a free month. If you aren't cool with that, just search for YNAB). They offer a month long free trial if you feel like giving it a shot.

Read more here

Cloudflare

According to their website, Cloudflare now powers nearly 10 percent of all Internet requests. I've been using them for a few years now and I'm still in awe of them. First of all, when I started using them I was still paying for SSL certificates, then here comes this start-up that offers DDoS protection, SSL and caching and it's free... Where's the catch? I do find it somewhat suspicious that they're able to offer these services for free. Presumably the money they make off enterprise accounts offsets the usage at the free tier.

The DNS settings are really easy to use too. I use the analytics on this site and it seems to block a few threats a week.

They are now offering domain registrations which I haven't taken advantage of, but they seem to be cheaper than your run of the mill registrar.

They also do a lot of very interesting technical writing. Curious why their office has a wall covered in lava lamps?

Technical version - https://blog.cloudflare.com/lavarand-in-production-the-nitty-gritty-technical-details/ Non-technical version - https://blog.cloudflare.com/randomness-101-lavarand-in-production/ Article about it - https://www.fastcompany.com/90137157/the-hardest-working-office-design-in-america-encrypts-your-data-with-lava-lamps

Check them out: https://www.cloudflare.com/

1Password

Password managers are certainly rising in popularity and it's a good thing. The password is a very flawed authentication method especially when you re-use the same weak password across multiple sites. If you can instead remember one very strong password, you'll be able to generate strong, unique passwords for every service you use. They also now have built in support for the Google Authenticator protocol with TOTP tokens.

I really like the mobile and desktop apps and they have recently released a browser only client. Along with their provided cloud sync options, they also offer personal cloud storage syncing.

You can also enable travel mode for when you're overseas which stops syncing sensitive vaults.

I use the shared vaults a lot to share with coworkers.

I'm planning on keeping this list updated should anything change, so keep your eyes on this post.

"Agile" in its current sense appears to be derived from the Agile manifesto, however, agile practices have roots through the last 4 decades of programming history. Recently I read the Mythical Man Month (Brooks, 1975) and in it Brooks extolls the virtues of things like disposable prototypes, testing as you build, and always having a working program.

One of the most recognisable and user-friendly explanations of this concept is "The Agile Bicycle" illustrated by Henrik Knilberg

This is a great example of delivering a minimum viable product (MVP). There are many benefits to this method:

Regardless of how rough around the edges your product is, if it is functional, then people can use it. It may not have the appeal to gain significant traction, but you can start getting at least some ROI, and - perhaps more importantly – user feedback. If a product is fundamentally flawed, it should be visible at any stage. According to Brooks, an incremental build method is better because:

• We can begin user testing very early, and
• We can adopt a build-to-budget strategy that protects absolutely against schedule or budget overruns (at the cost of possible functional shortfall)

The most important part of that is that while we may not deliver the full feature set at the initial release date, at the very least, we’re not going to be giving people a car without a steering wheel.

So, how does a company selling pre-packaged meals relate to software MVPs?

I’ve been using them for around a year. I picked them because unlike similar competitors, they offered meals with higher calorie counts for a similar price point. My first delivery came in an unmarked Styrofoam box. Styrofoam is good at insulating contents; however, it requires specialised machinery to recycle and takes untold millions of years to degrade, it’s not a great material. The meals came in take-away style containers with a sticker slapped on which were easily broken in transit and they were all frozen. On the technical side, subscriptions were not manageable by the user and had to go through customer service, which added some friction. It wasn’t a mind-blowing experience, but the meals all tasted good and most importantly, the business model worked.

Over the last 12 months I’ve observed various improvements to their offering.

1. They replaced the Styrofoam boxes with wool insulated cardboard boxes

2. They replaced the take-away style containers with vacuum sealed containers to allow the foods to last longer without being frozen. This paved the way for them to start offering fresh meals (which they have as of this week)
3. They upgraded their online services so that users can edit their subscriptions and more easily delay or cancel orders.
4. They improved their distribution to where they are now sold in retail spaces around the country, rather than simply being a drop at the door delivery service

While people starting to use them now will see the last year of enhancements as the norm, people who have been using it for a longer period will have gradually had improved service, thus increasing satisfaction. Rather than overreaching and increasing the risk of being crushed by their overhead, My Muscle Chef took an iterative approach and gradually built a loyal base of customers which enables further innovation.

In my eyes, iterative development is inarguably superior to traditional waterfall project management where oftentimes budget, schedule and feature set are inflexible. As the saying goes, "you don’t know what you don’t know", and as such, progressive discovery will often prove many of your initial assumptions incorrect. It’s very refreshing to see companies with more tangible products embracing Agile principles and prospering. As they say, the proof is in the pudding.

To be clear, I am in no way affiliated with this company, I just like eating their food. If you do end up signing up, consider using my referral code (S1HKD51IM) and we’ll both get $15 credit. Love those free meals.

At the time, I didn't want to sink a lot of time into it, so WordPress was identified as the path of least resistance. I used Bedrock by Roots to version control my plugins and WordPress with Composer. It was working well and was quite fast (for a WordPress website), but it still suffered from a fairly fundamental issue of not being able to version control content. WP apologists might tell you to store your database dumps in your repo, but to them I say; "yeah, nah". If you ever have the misfortune of looking at a WP database dump, you'll realise there’s about a billion lines of muck which is totally irrelevant to the content and composition of your website and I don’t particularly like the idea of storing my users table in a public git repository anyway. In spite of my whinging, the version controlled content pain point was more of an under-the-tongue ulcer type of pain than a broken arm so I didn't worry about it. One day I made the mistake of upgrading the WP version on my server and I hadn't copied the install to my local, so there was a lot of out of sync content. So you can imagine I was pretty happy when I found out my login no longer worked, I couldn’t reset my password and changing the password directly in the database didn't work. I took an sql dump of the database and loaded it into my local only to find the Advanced Custom Fields don’t appear to be stored in the database, so when I salvaged the content it was totally broken.

Then it hit me. What if I get a JSON dump of my posts from the database and turn that into a static version? So, what output format would be most suitable for an archive of text posts?

Markdown: A New Hope

Markdown was invented by notable 'f-word' writer John Gruber in 2004 and it has since become a staple in the development world. I chose to use Markdown as the output because it provides simple shorthands to represent markup so I knew I could get tidy archiving in Github that would be nicely rendered as html in the web view, but the posts would still be readable (and writable for future posts) when looking at the source. I created a node package for generating an archive and published it to npm in the hopes that it might address the problem for other people too.

Now I have my posts nicely sorted and stored in a repo, but the problem with generating an archive of Markdown files is then you just have an archive of Markdown files to deal with.

The website is built with the static site generator "Gatsby", so all pages are React components which really adds a lot of flexibility. For example, when generating blog post components I can make the title render as a link to the blog post slug but only when it appears on the front page.

The ingestion strategy is to add the blog-posts repository as a submodule so I can then update and push those independently. Then, at compile time, I would read the archive of blog posts and generate:

1. A root blog page that lists the content of posts in reverse-chronological order with pagination
2. An individual page for each blog post.

The script that is responsible for this is really something to behold (you can see that here). The process is such that all markdown files are grabbed from the archive, then for each post, the script will parse out a metadata table in the top of the file that has the post title and whether or not it is a draft. That post is then passed to the markdown renderer and we generate a blog post component with that rendered content. That blog post component is then given its own page component and it’s stitched onto the aggregate blog post list. The blog post list is then parsed out into pages which are output as components and voilà. I suppose if there’s a gap for it, I could publish a "WordPress Markdown archive to React static site" package, but it may be a bit too niche.

The end result is an overall slimmer repository since all of the blog posts are stored in a different repository and the generated pages are not committed which lends itself perfectly to an automated deployment service. It also allowed for much less human intervention in the creative process.

The main caveat I’ve discovered in this transition is that I didn't have a solution for porting assets (such as embedded images) to the markdown archive. Currently, any embedded images will 404 until they are added manually. This definitely isn't ideal and if I ever get a chance I plan to package all the linked assets down into each blog post.

Term 1

A longer definiton. A definition usually expands on the term.🌚

Term 2

A longer definiton. A definition usually expands on the term.🌚

But what if we want the term and definition to sit inline? This usage is semantically a dl, but traditionally, this has been a serious pain in the ass if you want consistent spacing between the terms/definitions. The image below exhibits a compromise I made with the designer on a previous project. Making the dt/dd inline-block works to a certain degree, however, when setting widths explicitly you will have serious issues going down the breakpoints. The display:block span just forces the content to stay in it's respective line. This, however, is not correct usage, as a dl is only supposed to have dt or dd elements inside it. EDIT: Since working on this project, it looks like we're now permitted to wrap a dt+dd group in a div to control flow. So how can flexbox help us here?

// Define base component styles (e.g. sizing/positioning)
.button {
  border: 1px solid;
  padding: 6px 5px;
}

// Dark Color scheme styles
.scheme-dark {
  .button {
    background: white;
    border-color: white;
    color: black;
  }
}

// Light Color scheme styles
.scheme-light {
  .button {
    background: black;
    border-color: black;
    color: white;
  }
}

Although this is quite lightweight, there are still issues.

1. It puts a hard dependency on codebase changes to add, remove or modify themes,
2. It makes user defined colour schemes all but impossible
3. Simple component partials are no longer neat self-contained partials with one selector defining all the component styles
4. There are several cases where I need to have colours that contradict the global colour scheme (e.g. black text for the white modal dialog) and it requires the use of !important and many colour overrides.
5. The extensibility of the approach is very limited because as more themes are added, the stylesheets WILL get bloated and overweight.

Enter the CSS Variable (the hero we need) CSS Variables are defined like so:

:root {
  // Initialise the variable
  --primary-color: pink
}

p {
  color: var(--primary-color); // it's pink, baby.
}

The var function also takes a second argument which is an initial/fallback value.

p {
  color: var(--primary-color, red);
}

CSS Variables follow block scoping principles, so, variables defined in :root are considered to be global variables (but may be overwritten inside specific components) and variables defined in any other element are scoped to that block of styles. This is broken down very nicely on a recent Smashing Magazine article.

How can CSS Vars help Agander?

I recently wrote a library to ingest variable names and values and spit them onto the root element (see the package) The idea is that each theme would have all relevant variables defined in objects like so:

const viewState = {
  currentTheme: 'darkScheme'
}

const themes = {
  darkSheme = {
    'primary-color': {
      hex: '#FFF'
    }
  },
  lightScheme: {
    'primary-color': {
      hex: '#000'
    }
  }
}

And then when the currentTheme changes:

import syncVars from '@lukeboyle/sync-vars';

function updateCssVariablesWithCurrentScheme(colorScheme) {
  syncVars(themes[colorScheme]);
}

// if we call that function with 'darkScheme'
updateCssVariablesWithCurrentScheme('darkScheme');

<html style="--primary-color: #FFF;"></html>

So, how does this help? For one thing, with this approach, I no longer have to worry about adding the colour scheme classes to the body, and I don't have to do any hacky overrides, etc. _buttons.scss now looks like this:

.button {
  border: 1px solid var(--text-color-var);
  padding: 6px 5px;
  background: var(--button-background-color-var);
  color: var(--text-color-var);
}

Looking forward, this approach also means that custom colour themes are very nearly in reach. It also means that colour schemes could be changed on the fly. The user could have a colour swatch tool and be previewing their theme changes live. Taking it even further, it means that the colour schemes no longer need to be a part of the codebase. It could just as easily be a JSON file on the server and changes could be flexibly pushed. Why is this exciting? Say it's Christmas time and you want to get into the spirit of things... With a few string replacements you have a temporary festive theme to force upon your users.

Other Applications

Accessibility

Sites or apps could have buttons to activate color blind mode and specific 'problem' colours could be swapped out for friendly colours. Additionally, high contrast modes would be a breeze.

Easter Eggs

Users could activate alternate modes for websites to get a different experience.

Retrospective

CSS variables are getting me really excited because it's the first minimal overhead approach to theming in front-end only applications. This is something that will reward well structured stylesheets and result in a better experience for the user. I am looking forward to rolling out custom themes in Agander and finally getting around to making the flat UI theme I have wanted to make for some time.

Option 1: Padding for vertical centering (Blue Pill)

<style>
    .button-padding-approach {
        font-size: inherit;
        -webkit-appearance: none;
        border-radius: 0;
        border-style: solid;
        border-width: 0;
        cursor: pointer;
        font-weight: normal;
        line-height: normal;
        margin: 0;
        position: relative;
        text-align: center;
        text-decoration: none;
        display: inline-block;
        padding: 1rem 2rem 1.0625rem 2rem;
        font-size: 16px;
        background-color: #999;
        color: #000;
        max-width: 170px;
    }
</style>

<div>[A Button](#) [A Button that breaks to two lines](#)</div>

This approach works okay, and it's good for multi-line (buttons where the marketing team sanctioned too much copy) text. The problem with typography, is that glyphs can have descenders (as in y and j) which push the bottom of the bounds down. So if you want to properly vertically center your text you have to baby the padding so much that it becomes too much of a pain in the ass. The padding on the above buttons is padding: 1rem 2rem 1.0625rem 2rem;. 5 significant figures for bottom padding? I don't think so.

Option 2: Line Height for vertical centering (Red Pill)

<style>
    .button-lineheight-approach {
        -webkit-appearance: none;
        border-radius: 0;
        border-style: solid;
        border-width: 0;
        cursor: pointer;
        font-weight: normal;
        line-height: normal;
        margin: 0;
        position: relative;
        text-align: center;
        text-decoration: none;
        display: inline-block;
        font-size: 16px;
        background-color: #999;
        color: #000;
        max-width: 170px;
        height: 50px;
        line-height: 50px;
        padding: 0 2rem 0;
    }
</style>

<div>[A Button](#) [A Button that breaks to two lines](#)</div>

This approach is a lot less hands on for the vertical alignment. You set height: 50px; and line-height: 50px; and voila, perfect vertical alignment. Until you need two lines and then it bleeds out of the button because you thought a CTA would never be more than 3 words long. At this point you're forced to either increase the button width, or reduce your font-size and neither are very designer friendly.

Option 3: Flexbox (dubbed by me as the green pill)

<style>
    .button-flexbox-approach {
        display: flex;
        justify-content: center;
        align-items: center;
        -webkit-appearance: none;
        border-radius: 0;
        border-style: solid;
        border-width: 0;
        cursor: pointer;
        font-weight: normal;
        line-height: normal;
        margin: 0;
        position: relative;
        text-align: center;
        text-decoration: none;
        padding: 1rem 2rem 1.0625rem 2rem;
        font-size: 16px;
        background-color: #34495e;
        color: #fff;
    }
    .button-flexbox-approach:hover {
        color: #fff;
    }
    .flex-button-container {
        display: inline-block;
    }
</style>

<div>
    <div class="flex-button-container">[A Button](#)</div>

    <div class="flex-button-container" style="max-width: 170px;">
        [A Button that breaks to two lines](#)
    </div>
</div>

The main caveat of this approach is that the button now needs a container. The container doesn't need anything fancy on it, just display: inline-block; to allow the content to naturally scale, and if you want to restrict how large the button can be, add max-width: x; Other than that, this approach is pretty bullet-proof from my testing and I like it a lot.

<script type="text/javascript">

  var flagValidation;

  /* validation for 'phone number' */
  function PhoneNumberValidation() {
    var phoneNum = document.getElementsByName("Phone")[0].value;
    var normalPhonepattern = /^[0-9\s\-\+]{6,14}$/g;

    if(!normalPhonepattern.test(phoneNum))
    {
      flagValidation = false;
      document.getElementById("PhoneValidation").innerHTML = "Only numbers, '-' and '+' characters are accepted"
    }
    else
      document.getElementById("PhoneValidation").innerHTML = ""
  }

  function SubmitDetails(){
    flagValidation = true;
    PhoneNumberValidation();

    return flagValidation;
  }

</script>

So what is wrong with this picture? - There's no reason for this to be a script tag on the page, let's make it an external script - Mutation - Basing the validation on mutating the variable to false should not be the responsibility of these functions - The flagValidation variable being globally scoped and mutated/used in several places leaves a lot of places for it to fail when making changes - The functions are doing too much. When looking at it from a functional standpoint, they should just be returning a bool, and a final validate function can follow up. - Repeating code (e.g. document.getElement...) unnecessarily When you allow your functions to be purely functional, this function...

  function PhoneNumberValidation() {
    var phoneNum = document.getElementsByName("Phone")[0].value;
    var normalPhonepattern = /^[0-9\s\-\+]{6,14}$/g;

    if(!normalPhonepattern.test(phoneNum))
    {
      flagValidation = false;
      document.getElementById("PhoneValidation").innerHTML = "Only numbers, '-' and '+' characters are accepted"
    }
    else
      document.getElementById("PhoneValidation").innerHTML = ""
  }

Can become...

function isPhoneNumberValid() {
  const phoneNumber = document.getElementsByName("Phone")[0].value;
  const phoneNumberRegex = /^[0-9\s\-\+]{6,14}$/g;
  return phoneNumberRegex.test(phoneNumber);
}

Much prettier, right? Once we've refactored all of those individual functions, the main input validation function looks like this:

function validateFormInputs(event) {

    let isFormValid = true;
    const phoneNumberFeedback = document.getElementById("PhoneValidation");

    if (isPhoneNumberValid()) {
        phoneNumberFeedback.innerHTML = '';
    } else {
        phoneNumberFeedback.innterHTML = "Only numbers, '-' and '+' characters are accepted";
        isFormValid = false;
    }

    if (isFormValid) {
        contactForm.removeEventListener('submit', validateFormInputs);
        return true;
    } else {
        event.preventDefault();
    }

}

It's cleaner, sure, but I'm still not okay with using and mutating that isFormValid variable and innerHTML appearing every other line. Let's take it further. Let's outsource the error message work to a utility function.

function generateErrorMessage(element, message) {
  return element.innerHTML = message;
}

// So we use that like this...

if (isPhoneNumberValid()) {
  generateErrorMessage(phoneNumberFeedback, '');
} else {
  generateErrorMessage(phoneNumberFeedback, 'Cannot be empty');
  isFormValid = false;
}

The next step is to stop mutating that validity flag. To do this, I'm going to bundle all the validation methods into an object and then reduce that to return an isFormValid bool.

const fields = {
  phoneNumber: {
    isFieldValid: function() {
      const phoneNumber = document.getElementsByName("Phone")[0].value;
      const phoneNumberRegex = /^[0-9\s\-\+]{6,14}$/g;
      return phoneNumberRegex.test(phoneNumber);
    },
    userFeedbackElement: document.getElementById("PhoneValidation"),
    errorMessage: "Only numbers, '-' and '+' characters are accepted"
  }
};

// Generate an array from the keys of the methods object and reduce
Object.keys(validationMethods).reduce((acc, curr) => {
    // do stuff
}, true);

If you're not familiar with Array.reduce, it will iterate over each item in the array and allow you to process them. The arguments are acc (accumulative) and curr (current). The idea is, we're going to execute each function and then show/hide error messages accordingly. The function now looks like this:

function validateFormInputs(event) {

  const isFormValid = Object.keys(fields).reduce((acc, curr) => {
    const currentField = fields[curr];

    if (currentField.isFieldValid()) {
      generateErrorMessage(currentField.userFeedbackElement, '');
      return acc;
    } else {
      generateErrorMessage(currentField.userFeedbackElement, currentField.errorMessage);
      return false;
    }
  }, true);

  if (isFormValid) {
    contactForm.removeEventListener('submit', validateFormInputs);
    return true;
    } else {
      event.preventDefault();
  }

}

This implementation is clearly a case-by-case basis. It works for my particular scenario because there's only one validation condition for each field. If there were more rules, the approach would need to be changed to compensate and it may not be able to be as dynamic. It should also be noted that this is a fairly over-engineered solution. I wouldn't say that the original approach is wrong, but my approach looks at the same problem from a functional programming standpoint and I believe it is much cleaner and much more robust. For a view of the entire file, see my gist at https://gist.github.com/3stacks/c5c49904684e4ddec48aa017ab912db9

{
    "sizes": ["320x480", "1280x768", "1920x1080"],
    "pages": [
        {
            "name": "homepage",
            "url": "http://localhost:3000/",
            "components": ["hero", "all"]
        }
    ],
    "components": [
        {
            "name": "all",
            "selector": "body"
        },
        {
            "name": "hero",
            "selector": ".hero"
        }
    ]
}

Since I'm generally against installing npm packages globally (and you probably should be too), I define my capture scripts in package.json. This presents the first issue: The usage of Argus is like so: argus-eyes capture <branch-name> But this of course only names the capture for you. It's your responsibility to switch branches. So the workflow becomes:

• Clone develop branch
• run argus-eyes capture develop (this is the baseline)
• Clone feature-branch-name
• run argus-eyes capture feature-branch-name
• run argus-eyes compare develop feature-branch-name

Argus then uses blink-diff to compare the two sets of screenshots you just captured (note, you shouldn't change your config between captures) and outputs any screenshots in which there are visual differences. For example, bumping the padding on your nav will result in something like this. It's not a super intelligent representation, however, it does quickly show you that something is wrong. In my opinion, the current workflow makes it almost worth not bothering. So how do we make it a 1 step test?

Automation

I am attempting to simulate this entire process in node. For this, we'll need a few things.

• The ability to use git functions in node (http://www.nodegit.org/)
• The ability to execute console commands in node (for this, I am using shelljs)

I've tried to make the node script as pure as possible. I created a file called argus-test.js. In that, there is an individual function for each git action. First is a function to initialise the repo.

/**
 * @param {string} path - path to the repository (.git)
 * @returns {Promise}
 */
function openRepository(path) {
    return Git.Repository.open(path);
}

// Path is based on current working directory
const repoPath = require("path").resolve("./.git");

openRepository(repoPath).then(...)

openRepository returns a Promise which has the reference to the repository in it. To act on the repository, we need to keep track of this returned value. Since all of the nodegit functions return Promises, we're going to be seeing a lot of then.

// Initialise this let to keep track of which branch we're on
let featureBranch;

/**
 * @param {Repository} repo - The reference to the repository object
 * @returns {Promise}
 */
function saveCurrentBranch(repo) {
    return repo.getCurrentBranch();
}

openRepository(repoPath).then(
    repo => {
        saveCurrentBranch(repo).then(repoName => {
            featureBranch = repoName;
        });
    },
    err => {
        // Usually would only happen if you give it the incorrect path
        throw new Error(error);
    }
);

Now we have a reference to the current feature branch, we've got that stored for later. In the function where we set the featureBranch variable, we're going to execute our capture functions.

shell.exec(
    `node node_modules/argus-eyes/bin/argus-eyes.js capture ${featureBranch}`
);

// Successful output will say something like "12 screenshots saved to .argus-eyes/feature-branch-name"

This is the tricky part. We have to switch branch to whatever the base is (develop in this case). This is the biggest hurdle. Although the function is simple, if there are any uncommitted changes, the function may fail. Probably best to warn the user to make sure all changes are committed or stashed first.

/**
 * @param {Repository} repo - The reference to the repository object
 * @returns {Promise}
 */
function switchToDevelop(repo) {
    return repo.checkoutBranch('develop');
}

switchToDevelop(repo).then(...)

After successfully changing to develop, we still have to capture the branch and then compare them, which is done like so:

shell.exec('node node_modules/argus-eyes/bin/argus-eyes.js capture develop');

shell.exec(
    'node node_modules/argus-eyes/bin/argus-eyes.js compare develop ' +
        featureBranch
);

If Argus detects any screenshots over the threshold for change, it will save the diff in a folder like .argus-eyes/diff_develop_feature_branch_name For the full file in action, check out this gist: https://gist.github.com/3stacks/0976ef8a84c50c6096aea09dbbbebd88

Retrospective

To improve this process, it might be an idea to save the baseline diff in the repo and then overwrite it whenever you push to that branch. This would eliminate the need to switch over the branches.

const appState = {
    key1: {...},
    key2: {...}
}

and set the data like this:

localStorageManager.set('appData', appState);

The issue with this is you may not want key1 and key2 to be grouped together but don't want them to be tossed straight into the local storage. With namespaces you can do this:

localStorageManager.set('key1', key1, 'myAppState');
localStorageManager.set('key2', key2, 'myAppState');

This makes it easier to access all of your data at once while still keeping those keys theoretically separate. When accessing the namespaced data, you simply add the namespace as the second arg like so:

localStorageManager.get('key1', 'myAppState');

The app is now more robust internally and can handle cases of missing data better. It also uses the getItem and setItem methods internally instead of accessing the localStorage directly. To get started, install via npm with npm install @lukeboyle/local-storage-manager See the npm page with documentation and in depth instructions at - https://www.npmjs.com/package/@lukeboyle/local-storage-manager

travis.yml

Note that I'm using only latest node as that is the requirement for me

  language: node_js
  node_js:
    \- "node"
  before_script:
    \- export CHROME_BIN=chromium-browser
    \- export DISPLAY=:99.0
    \- sh -e /etc/init.d/xvfb start

The before_script is the special part, which points travis in the right direction for running Chrome. The last two lines are addressed in the karma docs linked above. Personally, I am using a separate karma config file, and I want to make the changes within that config file to keep my test script clean. My test script is:

"test": "karma start karma.config.js"

karma.config.js

const configuration = {
    files: [{ pattern: 'tests/**/**/**.*', watched: true }],
    customLaunchers: {
        chromeTravisCi: {
            base: 'Chrome',
            flags: ['--no-sandbox']
        }
    },
    frameworks: ['mocha'],
    browsers: ['Chrome'],
    failOnEmptyTestSuite: true,
    singleRun: true
};

if (process.env.TRAVIS) {
    configuration.browsers = ['chromeTravisCi'];
}

module.exports = function(config) {
    config.set(configuration);
};

Luckily, Travis sets the process env to TRAVIS and if we check for this, we set the configuration browsers to ['chromeTravisCi'] which is defined in the customLaunchers. Have whatever pre-processors you need in the configuration object and it should work fine when you deploy.

Getting Started

For my project I'm using Webpack and just default npm scripts. Whatever your choice for build process the important part is what you have configured your babel config or .babelrc with.

plugins: [
    'transform-runtime',
    'transform-vue-jsx'
],
presets: ['es2015']

That's the basic requirement for getting started. To install those, run:

• npm install -D babel-plugin-transform-runtime
• npm install -D babel-plugin-transform-vue-jsx babel-helper-vue-jsx-merge-props babel-plugin-syntax-jsx
• npm install -D babel-preset-es2015

The official repo for the Vue jsx is located here: https://github.com/vuejs/babel-plugin-transform-vue-jsx The interesting part about VueJsx in my opinion is that it follows the Angular pattern for registering components. Whereas in React you just import a function that returns jsx and you can name it whatever, in Vue jsx you must declare the name and register the component globally. Vue has a component method that takes a name and an object with all relevant data. The difference being is that instead of a template entry, there's a render function which returns jsx.

Vue.component('jsx-example', {
  render (h) { // <-- h must be in scope
    return <div id="foo">bar</div>
  }
})

// Usage

<div>
    <jsx-example/>
</div>

h is the shorthand for the Vue instance $createElement method so you have to make sure that h is in the scope of your components, like so:

const pageView = new Vue({
    el: '#root',
    data: {},
    methods: {},
    render () {
        const h = this.$createElement;
        return (
            <div>
                <jsx-example/>
            </div>
        )
    }
});

From the get go it seems to me like we've lost some of the versatility that jsx provides by having to integrate it into the normal Vue component pattern.

  return (
    <div
      // event listeners are prefixed with on- or nativeOn-
      on-click={this.clickHandler}
      nativeOn-click={this.nativeClickHandler}
      key="key"
      ref="ref">
    </div>

Considerations

There's a strange thing where on-change on a form input seems to be naturally debounced, and the nativeOn-change doesn't seem to be any different. The behaviour doesn't seem to be the same as the React class where you can refer to an element with this.refs, you need to use this.$refs which follows the usual Vue convention. Since there's no documentation surrounding the jsx, I'm assuming the rest of the behaviour follows the standard Vue component pattern, but instead of a template, there's a render function. The jsx doesn't support the normal vue directives so you'll have to do any of those things programmatically.

After much frustration with this issue, I found this section in the react material-ui documentation - React-Tap-Event-Plugin. The custom components like the select field don't work well with the traditional onClick listener, so as a temporary fix, the react-tap-event-plugin must be included in your react project. The dependency is supposedly a temporary fix. See the repo here: https://github.com/zilverline/react-tap-event-plugin

Disclaimer: Shopify is not good. I recommend steering clear and opting for one of many alternatives. It's an extremely closed platform that doesn't encourage innovation and naturally leans towards bad practice. Given this, if you still have to use it, read on.

In Shopify, there is a native (albeit 'unsupported') filtering system. Native Filtering is based on the tags you specify on your product. If you go to your collection, you can link the user to a tag and Shopify can filter product with simple Javascript like so; collections/collection-name/tag-one/tag-two. Now given that in a collection you have access to collection.all_vendors and all_types, WHY OH WHY, is there not native filtering based on that. Filtering could EASILY be dynamic if Shopify cared enough to implement that. The 'official' solution (as per the documentation; https://help.shopify.com/themes/customization/collections/filtering-a-collection-with-multiple-tag-drop-down) is to make several drop downs and set tags to be a list of tags you want to allow filtering by (e.g. tags = "red", "blue", "green"). So next week when I add a yellow shirt I have to go back into the pits and add another tag? Not happening. This is how I make filters dynamic. After searching for hours, I can conclusively say that there is no open source solution for this, and given the constraints of the garbage liquid templating engine, I can confidently say that this is the least convoluted solution available. All it takes is implementing a rigid structure in your tagging system, so this is much easier on a new store. The tag structure is basically as such: category:tagName. Let's say you want to filter your products by brand. In your product page, on the tags section, enter brand:brandName. Same goes for size:1 or color:blue. It's up to you how many you use, because I guarantee your collection sorting template is going to be a BIG file. The best part about all this is that there's no array filter or equivalent method in liquid, so we're going to have to do some crazy shit.

{% for tag in collection.all_tags %} <-- Start iterating over all tags
  {% if tag contains 'style' %} <-- Check if it contains your keyword
    {% capture raw\_style\_tags %} <-- Initialise the variable \`raw\_style\_tags\`
      {{ raw\_style\_tags | append : tag | append: ', ' }} <-- Build a string of tags separated by commas
    {% endcapture %}
    {% assign style\_tags = raw\_style_tags | split: ', ' %} <-- Split the strings on the commas to build a new array
  {% endif %}
{% endfor %}

The variable style_tags is now an array of all tags including 'style:'. Now, you will make a select field where the options are all of your style tags. Note that current_tags returns a list of the tags you are currently filtering by.

 Shop by style
  All
      {% for t in style_tags %}
        {% assign tag = t | strip %}
    {% if current_tags contains tag %} <-- check if the tag is currently active - applies selected attribute
      {{ tag | remove: 'style:' }}
    {% elsif product_tags contains tag %} <-- else, just make it an option
      {{ tag | remove: 'style:' }} <\-\- use the remove filter to have just the tag name
    {% endif %}
      {% endfor %}

If you include the Javascript from the Shopify docs, it will automatically listen for changes to that .coll-filter. This way, if you ever add any more tags under the style: category, you won't have to update your view. And the best part is, you can just add a new category in your product page, copy paste those lines of code and change 'style' to whatever your new category is called. I must reiterate, you should only use Shopify if you have no other choice. Cheers!

project-root

|--src
|  |--index.jsx
|--index.js
|--rollup.config.js (OR)
|--webpack.config.js
|--demo
|  |--dist
|     |--build files
|  |--src
|     |--src files

index.jsx

import * as React from 'react';

export default function ReactComponent(props) {
    return <div>Job's Done</div>;
}

Also, to play your part in improving our package ecosystem, consider namespacing your package for npm: http://blog.npmjs.org/post/116936804365/solving-npms-hard-problem-naming-packages

What's new?

Outwardly, the changes are minimal. The most obvious change is that the add module dialogue is now a modal instead of a floating column element. Various styles have been optimised and reduced as much as possible so the button sizes specifically are more consistent across browsers.

So why the new version?

Around three quarters of the way through version 1 it became apparent that the app was outgrowing the constraints of the Vue system I had created, so the app has been rebuilt in React.js and Redux. The standard module model Using this model, every module has a content object and an event object under it. The content object handles calendar events, Asana workspaces and so on. Adhering to this model will allow for rapid development of new modules in future. Events The event system is simulated using the Redux middleware called Thunk. The base dispatch will set the event to executing and it will continue to execute until it is told to stop. If error is true, the event stops executing and and the error response is populated in the response key. Error false means the event resolved correctly and the response is the delicious events or tasks. React also makes rendering the correct component a breeze. I know to hide all content if the user hasn't authorised, and if the event is executing. Error messages are nice and simple too. https://youtu.be/T43RzjxwBys Next Steps Agander is being temporarily put on hold to focus on other projects - but in its current state it is very much usable. Aside from bug fixes, there will be no new features for at least a couple months while I'm working on other things. I'm really happy with how far the app has come and I can finally use it for my own agenda tracking.

Color ID

Color Name

Hex Code

undefined

Who knows

#039be5

1

Lavender

#7986cb

2

Sage

#33b679

3

Grape

#8e24aa

4

Flamingo

#e67c73

5

Banana

#f6c026

6

Tangerine

#f5511d

7

Peacock

#039be5

8

Graphite

#616161

9

Blueberry

#3f51b5

10

Basil

#0b8043

11

Tomato

#d60000

• Authorise a user
• Display all tasks in a given tasklist
• Complete a task

Authorising the user and displaying their tasks is reasonably easy following the quickstart guide here. Essentially, requests are separated into two categories; either tasks or tasklists. When you have loaded the tasks api, you can see the basic structure and work from there. API Reference for JS To find the tasklists, you would use the list function (returns an array of tasklist objects).

function listTaskLists(gAPI) {
    var request = gAPI.client.tasks.tasklists.list({
        'maxResults': 10
    });
    request.execute();
}

Finding tasks in a given task list operates much the same way, however, you are dealing with Google here, so it's tasks.tasks.list... Basic parameters here would just be the tasklist you want to pull tasks from, however, there are other options.

function getTasksByListId(gAPI, tasklistId) {
    var request = gAPI.client.tasks.tasks.list({
        'tasklist': tasklistId
    })
        request.execute();

So, we've covered getting the tasks, how do we manipulate it? That's where the tricky part comes in. The gapi client interactions we used before have an update method. However. Whenever I called update on anything, I got a 400 error with 'Invalid Value'. This is a common issue I've observed online with no real solutions. The gist of it is, that there is a bunch of 'required parameters' for you to include in the request, but there is absolutely no documentation on this (thanks Google). To get around this, we found that it was simply easier to outright request it using the request method and giving it a url. The path parameter requires a tasklist Id, and a task id. This is basically the url that comes down with the getTasksByListId request. Make sure you define the method as PUT, and you pass the whole task object with your updated values to Google. In this instance, we are marking the task as 'completed' and giving it a completed timestamp.

function markTaskComplete(gAPI, task) {
    gAPI.client.request({
        path: 'https://www.googleapis.com/tasks/v1/lists/' + tasklistId + '/tasks/' + task.id,
        method: 'PUT',
        body: Object.assign(
            {},
            task.originalTask,
            {
                completed: new Date().toISOString(),
                status: 'completed'
            }
        )
    }).execute();
}

Now you have a basis, the world is your oyster.