05 February 2021

Ketogenic Foods Cheatsheet

This is a quick cheatsheet of ideal foods to consume whilst doing either a Ketogenic Diet or just a Low/Zero Carb Lifestyle in general. It’s an opinionated list that I’ve amended over the years which is focused on natural, organic, and whole foods.

Foods you SHOULD consume:

Meats

• Pork
• Bacon
• Ham
• Beef
• Egg yolks
• Fish
• Real-meat sausages

Nuts and Seeds

• Macadamia nuts
• Walnuts
• Brazil nuts
• Cashew nuts
• Chia seeds

Unsweetened Beverages

• Black coffee
• Green tea
• Kombucha
• Almond milk
• Coconut milk

Additives & Ingredients

• Butter
• Coconut oil
• Olive oil
• Almond flour

Vegetables

• Red/regular cabbage
• Kale
• Lettuce
• Broccoli
• Cauliflower
• Brussel sprouts
• Bok choy
• Collard greens

Fruits

• Avocadoes
• Tomatoes (not the seeds; they’re high in lectins)
• Lime juice (diluted in water, before meals)

Supplements

• Multi-vitamin
• Nutritional yeast
• Milk thistle
• Turmeric
• Vitamin D
• Vitamin C
• Magnesium
• Apple cider vinegar (diluted in water, before meals)
• Electrolytes
• Fish or Krill oil

Foods you SHOULD NOT consume:

Anything not on the above lists is to be avoided, but pay special attention to the following:

• Sugar
• Anything marked as “sugar-free” (they contain sugar-alcohols)
• All dairy products (including heavy cream and cream cheese)
• Alcoholic beverages (intermittently should be fine)
• Sodas
• Any sweetened “electrolyte” drinks
• Protein shakes
• Soy
• Alfalfa
• Corn
• Flax seeds
• Omega-6 fatty acids (canola and vegetable oils)
• Gluten (and ironically, anything marked as “gluten-free”)
• Junk or processed foods
• Any vegetables/tubers grown underground (high in carbohydrates)
• Anything marked as “genetically enhanced”, “genetically modified”, or “partially produced with genetic engineering”

03 February 2021

Quollated Redesign

Took some time yesterday to refactor Quollated  — my “curated quotes” side project — so as to give it a mobile-first facelift and a much needed redesign that focuses on typography and whitespace.

The above screenshot on the left is HTML/CSS that I initially hacked together to make it happen. I chose to replace that static file with a proper build pipeline instead comprising of Bootstrap, NPM, and Webpack; and while I’m not necessarily a fan of bundlers but since this is low-hanging fruit I figured why not. The new site is shown on the right.

01 February 2021

Jekyll, Hyde, and Hugo Walk into a Bar

When looking into the JAMstack and Static Site Generators (SSGs) for the first time, you’ll find a lot of folks that use either Jekyll or Hugo (and yes I see you staring me 11ty, Gatsby, Ember, and the rest of the gang; but I only have so much space to make the title into a bad joke).

Often times, the conclusion reached when comparing Jekyl and Hugo is that Hugo is a better choice because of it’s single Go binary and stupid-fast build times.

I think Jekyll however should be the first choice if you’re getting into static sites. I say this because of Jekyll’s maturity in the SSG ecosystem, it’s simplicity of theming, it’s similarly simple method of including templates, it’s extensive collections feature, easy-to-understand Ruby syntax, widely available documentation & tutorials, and it’s use of the Liquid templating language.

And yes, it’s slower than Hugo where build times are concerned, but is that really a problem? The best-practice for SSGs is to build locally anyway, and therefore I’m not fussy if my site takes 3s to build in Jekyll vs 300ms in Hugo, since the HTML output is the same (and that’s really the important bit, eh?).

The above being said, using Shopify’s Liquid Parser  (written in C) combined with adding incremental: true to Jekyll’s _config.yml (enabling incremental builds) will give hot-reloading times of 500ms to 1s when serving, and reduce overall build times by almost 70% in my experience.

Also, I use Netlify’s CLI  and recommend others do so, as building locally is orders of magnitude faster than letting Netlify (or GitHub/GitLab/Vercel) spin up a container runtime, verify dependencies, and execute a build. If one’s build workflow is local instead of remote, you’ll save valuable build minutes, have faster builds, and then the only bottleneck of sorts is the upload speed to where the site is being deployed.

And just to be clear, this is less of a post trying to vouch for Jekyll as it is an encouragement for others not to immediately dismiss Jekyll when looking at SSGs. Jekyll’s innate simplicity shines when website complexity rears it’s ugly head, and it can definitely hold its own at scale.

I do think everyone should try out different SSGs, especially if they’re written in a language you’re familiar with (and therefore have a runtime to utilize) or — and here’s my personal litmus test — if you can read the documentation in one pass and understand fundamentally what's going on.

So by all means give the gamut of SSGs a try, but don’t forget Jekyll; contained within it is a monstrously capable Hyde.