Friday, May 19, 2017

The meaning of VueJS "render: h => h(App)"

What is the meaning of the arrow function defining the 'render' VueJS method?:
import Vue from 'vue'
import App from './App.vue'

new Vue({
  el: '#app',
  render: h => h(App)
})
From https://vuejs.org/v2/guide/render-function.html
Aliasing createElement to h is a common convention you’ll see in the Vue ecosystem and is actually required for JSX. If h is not available in the scope, your app will throw an error.
Therefore here is the equivalent of the previous code:
import Vue from 'vue'
import App from './App.vue'

new Vue({
  el: '#app',
  render: function(createElement) {
    return createElement(App);
  }
})
The arrow function meaning is: let 'render' be a function that accepts the createElement() function as argument and that returns createElement(App) where App is a VueJS single-file-component. Here is a working example showing the equivalent of this arrow function. Below is the complete code as well:
<!DOCTYPE html>
<html>
<body>
  <div id="app">
  </div>
  <script src="https://unpkg.com/vue@2.3.3"></script>
  <script type="text/javascript">
    new Vue({
      el: '#app',
      // render is a function defined here as accepting the function h as parameter and returning the h result when evaluated with a single file component or in this case a template (in here two params: the tag and the value)
      render: h => h('h1', 'Hello')
      // Same but probably easier to understand for most humans who prefer long but straightforward text rather than short but cryptic:
      /*render: function(createElement) {
        return createElement('h1', 'Hello');
      }*/
    })
  </script>
</body>
</html>
BTW there is a cryptic-er way to use a single file component (the ES6 spread operator):
import Vue from 'vue'
import App from './App.vue'

new Vue({
  el: '#app',
  ...App
})

Sunday, May 14, 2017

kubectl get pods listing pods belonging to a different cluster

Issue: kubectl get pods lists pods belonging to a different cluster
Solution:
gcloud container clusters get-credentials your-cluster --zone your-zone --project your-project
gcloud config set project your-project

Saturday, May 06, 2017

GCS - Bad credentials for bucket - Check the bucket name and your credentials

Issue:
$ gcsfuse --key-file /path/to/credentials.json my-bucket /tmp/my-bucket/ daemonize.Run: readFromProcess: sub-process: mountWithArgs: mountWithConn: setUpBucket: OpenBucket: Bad credentials for bucket "my-bucket". Check the bucket name and your credentials.
Solution:
Give credentials access to the bucket: From the JSON file locate client_email, go to GCP Console / Storage / Browser / Select bucket / Edit Bucket permissions / Add Item / User:$client_email, access:writer

Tuesday, May 02, 2017

Find public IP of each instance and container pod in Google Cloud Platform

ERROR: (gcloud...) ResponseError: code=403, message=Required "..." permission for "projects/..."

Issue: I got the below after trying to access Google Container Engine from a MAC:
ERROR: (gcloud.container.clusters.list) ResponseError: code=403, message=Required "container.clusters.list" permission for "projects/myproject".
Solution: Run the below to make sure you select the right project (id, not name) and Google account:
gcloud projects list
gcloud config set project 
gcloud auth login

Friday, April 28, 2017

kubectl get pods - The connection to the server w.x.y.z was refused - did you specify the right host or port

$ kubectl get pods
The connection to the server  was refused - did you specify the right host or port
Solution:
$ gcloud container clusters get-credentials your-cluster --zone us-east1-b --project your-project
Other issues I have found that get resolved with the same command:
  • Unable to connect to the server: x509: certificate signed by unknown authority
  • Unable to connect to the server: dial tcp w.x.y.z:443: i/o timeout

Tuesday, March 14, 2017

Unit and End to End (e2e) Testing should be enough - the rest are intangible

I have learned from my years as full time developer that (those tests, that according to Google's classification are called medium), are a life saver. I have also learned from my years as a team leader that these tests are the perfect excuse to deliver tight coupled, AKA 3v1l untestable code.

If Unit tests are covering all the functionality of your loosely couple software and e2e tests are covering all common scenarios followed by your users, I would name the medium tests "intangible tests". They are useful as ad-hoc tests that aim at getting a proof of concept (POC) out of the door. However maintaining them, relying on them for application quality and delaying your delivery because of them will be nothing more than paying a big opportunity cost.

Quick Glossary:
  1. Small Tests: "Local Memory" Tests. Hopefully your current Unit tests.
  2. Medium Tests: "Local Host" Tests. Hopefully you don't maintain them.
  3. Large Tests: "Any Host" Tests. Hopefully your current e2e tests.
The local host tests should not be run as part of your pipeline. They are intangible. I would keep them in the project just for historical reasons, if I would ever keep them.

Followers