## Thursday, June 08, 2017

### The network folder specified is currently mapped using a different name and password

Getting "The network folder specified is currently mapped using a different name and password. To connect using a different user name and password, first disconnect any existing mappings to this network share"?

This happened to me after a failed attempt to map a path I had no access to with my regular user. Selecting to map it with different credentials kept on complaining with this error message. The solution was to:
1. Run 'net use' and if the path is present run 'net /delete \\path\to\resource' and/or 'net /delete $DRIVE_LETTER:' 2. Run 'runas /profile /user:$DOMAIN\$USER cmd' for any privileged$USER you have used before. Hopefully is not administrator ;-)
3. From the new command prompt pertaining to the privilege user follow the first step
4. Try to map the drive again as you would usually do (in my case using the "Connect using different credentials")

### tail: inotify cannot be used, reverting to polling: Too many open files

Run 'ps -ef' and look for some processes that might be unusually big in number.

## 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

### 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


## 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.