My friends and I went to go see Monuments. Holy hell. What and experience! This band was mind blowing. Mind blowing instrumentals all over the show with the most amazing vocals ever. 


Monuments - Origin Of Escape (Live in Cape Town - South Africa)


Live Rating: ⭐️ ⭐️ ⭐️ ⭐️ ⭐️


In the past my "blogs", and I'm hesitant to call it that, have had the unfortunate pleasure of being my lab-rat for exploratory development. As such, they tend to be somewhat unstable at the best of time. The previous longest running version was just github page with some Jekyll templates, it was fun to tinker with it but ultimately I got to thinking that I'd prefer to have my personal work space not be something I always fight against. As such, I give you blog 3.0


Tailwind (This is the only new framework I'm willing to add in) 

Prismic.io (using graphql, I've dabbles with it in the past, and it was super easy to get going)

Vercel... At work I've user CI/CD pipelines ranging from Jenkins, TeamCity, GitHub Actions (this is my current favourite), and to host varieties of containers or PaaS services on AWS... but nothing has been as simple as this. Literally 2 clicks, and the site was live. I can highly recommend it to anyone who'd like to do the same and keep it simple. (Oh and its free for personal/single user projects)

Over the last few months I've been delving deeper into the world of Webpack.

Below I'll demonstrate a few cool tricks that I've learned that really isn't as obvious as it should be, which I believe any dev that using Webpack will encounter at some stage or another.

Context: I'm using Webpack for an Angular2 project, thus I'm using TypeScript, and some of the examples are pertaining to TypeScript only solutions.


How to: Serve 3rd party JavaScript libraries

that do not have TypeScript wrapped modules (yet)... if working in TypeScript

Install the 3rd party module via npm, then expose it via an alias:

module.exports = {
  module: {
     resolve: {
        alias: {
            moment$: path.join(__dirname,'../node_modules/moment')
        }
     }
  } 
}


How to: Import Bootstrap and FontAwesome.


There are 2 amazing OpenSource projects: 
bootstrap-loader and font-awesome-loader, both made by the ShakaCode team.

To implement them, install via npm, and add the following to your Webpack entry point:

  entry: {
    vendor: [
      'font-awesome-loader',
      bootstrapEntryPoints.dev // bootstrapEntryPoints.js
    ]
  }

Then setup a helper service or point to the config path manually:

'use strict';

require('dotenv').config();
const fs = require('fs');

function getBootstraprcCustomLocation() {
  return process.env.BOOTSTRAPRC_LOCATION;
}

const bootstraprcCustomLocation = getBootstraprcCustomLocation();

let defaultBootstraprcFileExists;

try {
  fs.statSync('./.bootstraprc');
  defaultBootstraprcFileExists = true;
} catch (e) {
  defaultBootstraprcFileExists = false;
}

if (!bootstraprcCustomLocation && !defaultBootstraprcFileExists) {

  /* eslint no-console: 0 */
  console.log('You did not specify a \'bootstraprc-location\' '+'arg or a ./.boostraprc file in the root.');

  console.log('Using the bootstrap-loader default configuration.');
}

// DEV and PROD have slightly different configurations

let bootstrapEntryPoint;

if (bootstraprcCustomLocation) {

  bootstrapDevEntryPoint = 'bootstraploader/lib/bootstrap.loader?' +

    `configFilePath=${__dirname}/${bootstraprcCustomLocation}` +
    '!bootstrap-loader/no-op.js';    // for prod add loader?extractStyles

} else {
  bootstrapDevEntryPoint = 'bootstrap-loader';  // for prod replace with 'bootstrap-loader/extractStyles'
}

module.exports = {
  dev: bootstrapEntryPoint
};

 ...and add a *.bootstraprc* file. This will allow you to manually configure and cherry pick features for your bootstap build.

# Output debugging info
# loglevel: debug
# Major version of Bootstrap: 3 or 4

bootstrapVersion: 3

# If Bootstrap version 3 is used - turn on/off custom icon font path
useCustomIconFontPath: false

# Webpack loaders, order matters

styleLoaders:
  - style-loader
  - css-loader
  - sass-loader

# Extract styles to stand-alone css file
# Different settings for different environments can be used,
# It depends on value of NODE_ENV environment variable
# This param can also be set in webpack config:
#   entry: 'bootstrap-loader/extractStyles'
# extractStyles: false
# env:
#   development:
#     extractStyles: false
#   production:
#     extractStyles: true

# Customize Bootstrap variables that get imported before the original Bootstrap variables.
# Thus original Bootstrap variables can depend on values from here. All the bootstrap
# variables are configured with !default, and thus, if you define the variable here, then
# that value is used, rather than the default. However, many bootstrap variables are derived
# from other bootstrap variables, and thus, you want to set this up before we load the

# official bootstrap versions.
# For example, _variables.scss contains:
# $input-color: $gray !default;
# This means you can define $input-color before we load _variables.scss

# preBootstrapCustomizations: ./src/scss/bootstrap/pre-customizations.scss
# This gets loaded after bootstrap/variables is loaded and before bootstrap is loaded.
# A good example of this is when you want to override a bootstrap variable to be based
# on the default value of bootstrap. This is pretty specialized case. Thus, you normally
# just override bootrap variables in preBootstrapCustomizations so that derived
# variables will use your definition.

#
# For example, in _variables.scss:
# $input-height: (($font-size-base * $line-height) + ($input-padding-y * 2) + ($border-width * 2)) !default;
# This means that you could define this yourself in preBootstrapCustomizations. Or you can do

# this in bootstrapCustomizations to make the input height 10% bigger than the default calculation.
# Thus you can leverage the default calculations.
# $input-height: $input-height * 1.10;
# bootstrapCustomizations: ./src/scss/bootstrap/customizations.scss

# Import your custom styles here. You have access to all the bootstrap variables. If you require

# your sass files separately, you will not have access to the bootstrap variables, mixins, clases, etc.

# Usually this endpoint-file contains list of @imports of your application styles.

appStyles:

# ./src/scss/_custom.scss

### Bootstrap styles

styles:

  # Mixins
  mixins: true

  # Reset and dependencies
  normalize: true

  print: false

  glyphicons: true

  # Core CSS

  scaffolding: true
  type: true
  code: true
  grid: true
  tables: true
  forms: true
  buttons: true

  # Components
  component-animations: true
  dropdowns: true
  button-groups: true
  input-groups: true
  navs: true
  navbar: true
  breadcrumbs: true
  pagination: true
  pager: true
  labels: true
  badges: true
  jumbotron: true
  thumbnails: true
  alerts: true
  progress-bars: true
  media: true
  list-group: true
  panels: true
  wells: true
  responsive-embed: true
  close: true

  # Components w/ JavaScript
  modals: true
  tooltip: true
  popovers: true
  carousel: true

  # Utility classes
  utilities: true
  responsive-utilities: true

### Bootstrap scripts

scripts:
  transition: true
  alert: true
  button: true
  carousel: true
  collapse: true
  dropdown: true
  modal: true
  tooltip: true
  popover: true
  scrollspy: true
  tab: true
  affix: true

...like API paths, or environment specific static properties

Webpack had various ways of doing this but the route that worked the best for myself was to have each environment have its own .env file, and have Webpack map the properties inside the .env to its appropriate property within the app.

// npm install dotenv --save-dev
// dotenv is a super simple way to access .env files

require('dotenv').config();

new webpack.DefinePlugin({
    "process.env": {
       // process.env in this instance 
       // does not equal the runtime process.env of the app.
       "KEY": process.env.KEY,  
       "FOO": {   
         //  think of Webpack and the running 
         // application of having 2 separate contexts 
         "BAR": "yolo",
         "BOOLEAN_PROPERTY": true
      }
    }
})

Once your solution become more sizeable you might notice that it can get a bit slower from time to time, especially when using something like TypeScript. The below are a few options that you can make use of, depending on your use case.

* Use HappyPack to multithread certain loaders.

var HappyPack = require('happypack');

var happyThreadPool = HappyPack.ThreadPool({size: 5});

module.exports = {
  module: {
    loaders: [
      {
        test: /.html$/,
        use: ['happypack/loader?id=html'],   // <---- loader?id=BUNDLE_ID
        exclude: /node_modules/
      }
    ],
    plugins: [
      new HappyPack({
        id: 'html',                          // <----- BUNDLE_ID
        threadPool: happyThreadPool,
        loaders: ['html-loader']             // loaders for this specific bundle
      })
    }
}

* Have specific dev build options to toggle source maps on or off (depeding on the task at hand)

// eval === fast, but not very useful, source-maps === useful, but slower (in larger projects)
 devtool: process.env.ENVIRONMENT === 'dev' ? 'eval' : 'source-maps'     

*  Set transpileOnly to true. If you want to speed up compilation a lot you can use this option, but you end up losing a lot of benefits. docs

 loaders: [
    { 
      test: /\.ts?$/,
      loader: 'ts-loader?' + JSON.stringify({
        transpileOnly: true
      }) 
    }
 ]

As of Webpack 2 and some of the plugin updates that go along with it there has been an issue with bootstrap-loader.

Module not found: Error: Cannot resolve module '[object Object]./lib/bootstrap.styles.loader.js' in /home/user/work/project/node_modules/bootstrap-loader
 @ ./~/bootstrap-loader/lib/bootstrap.loader.js!./~/bootstrap-loader/no-op.js 1:21-1087

There are some breaking changes to the ExtractTextPlugin where the output format has changed from:

[{ loader: 'style-loader', options: {...} }, { loader: 'css-loader', options: {...} } ]

The temporary fix for this is to run the script (I can't claim credit for it though...)

In summary the script alters the buildExtractStylesLoader.js output to return the old format. Read more about the issue on this thread

I've been self taught on guitar for the better part of 20 years, and have always avoided theory being in the school of thought that the lack of knowing the boundaries so to speak would not make my conform to normal music standards, e.g I always thought it was more punk or metal to just wing it... but as I've grown older I found that, that is not the case, and at least knowing some basics does actually help with things like song composition. So this is my post on my learnings around the CAGED system.

The CAGED system in layman's terms would be taking your standard open chords, and then shifting them down the neck of your guitar.

Open C would equate to a Barred Open A shape on fret 3 and so on (you'll need to modify your grip as avoid the need to get tendonitis, or grow an extra finger)

If this all sounds like a bunch of random words spewed out by someone who doesn't know much, then fear not... I have pictures.

The below is the progression of C though all the shapes... C -> A -> G -> E -> D

As you'll have probably noticed, the name CAGED is of actual importance as well, as your starting chord, determines the shape progression.

If I start on an Open A, the progression to make an A sound down the neck would be (AGEDC):

(2nd Fret) Barred on 2, G shape (aka. Crab hand. This is a bit of a stretch though, no one would do this in their right mind).

If I started on E the the progression would be EDCAG

Hope this helps anyone out there, whose wanting to learn some basics as well.

We have an internal news feed like system with various other features that's crucial to our companies way of life. Think Facebook but for the working class.

The specific pain point was, that one specific text-box that I'd like to have resizable was not, which was an issue when writing larger posts. I started toying with the idea of doing a small CSS alterations via a Chrome extension called Stylish since it seemed super simple, just modify the CSS right? Wrong. Stylish worked, but wasn't able to solve my problem due to the following issues: 

One of the quirks of this application is that it's written in GWT utilising a "portlet" style system. In terms of "code" being delivered to the browser we have the following flow:

all primary dependent code paths and libs get pushed down, top level CSS and JS, etc.. 

after that, the rest of the DOM gets constructed, via GWT deciphering its payload 

and then lazy loading sub sections of the application 

Because of the lazy loading, Stylish wasn't able to alter the CSS before it being rendered by the browser (as the CSS I was after, is deep down the tree structure). 

Take 2.

A colleague then noticed what I was doing, suggested that we try another approach, and asked if we can team up to do some other smaller tweaks as well while solving the above (He wanted additional markdown support). We then decided upon TamperMonkey, as it was clear we needed some JS to do heavy lifting.

We then hit a similar issue with the JavaScript due to the lazy loading... and then I remembered the following. It's all DOM mutations :D. Such a simple solution to this problem.

Checkout the docs: Mutation Observer. 

And below is an extract of my script. Observe a section of the page, if we find the 

The MutationObserver at the end of the rabbit hole

I don't know if anyone else feels the same... but I always get the feeling that when an app update gets pushed through and we get the generic answer of "we fixed teh bug" I feel somewhat betrayed because the update might as well read. Updated spy software to v5.9... 

OK given, I have over the course of my career done some pretty dirty commits too (which equates to the same as the above). But generally I have found when a project kicks off things tend to be messy, but as a solution matures, commits get more concise as they help maintain traceability.

I guess my expectation is that these products that are released to the public and are well known already, fall in the latter bucket, so my feeling is they don't get to be as hacky anymore.

Hopefully someone out there from these companies sees this, and does something about it.

Guitar Heroes: Monuments

Guitar Heroes: Monuments

More Stories

Hello 3.0 World

Hello 3.0 World

Webpack Tips and Tricks

Webpack Tips and Tricks

Bootstrap Loader Bug

Bootstrap Loader Bug

CAGED System

CAGED System

The MutationObserver at the end of the rabbit hole

The MutationObserver at the end of the rabbit hole

My thoughts on app release notes

My thoughts on app release notes