The first and most simple thing this API provides is a property on the document that lets you know if the page is currently hidden. To run a quick test, open the console on this very page (cmd + option + j on Mac) and type:

document.hidden

As expected this should print:

false

Obviously, the page you are currently viewing is not hidden. But now type this into your console:

setTimeout(function() { console.log(document.hidden); }, 4000);

and immediately switch to another tab. Wait at least four seconds and switch back to this tab. You will now see:

true

This is because the page was hidden when the timeout callback fired.

There are three possible visibility states: hidden, visible, and prerender. hidden and visible are self-explanatory, and prerender is simply the state before the page is fully rendered while the tab is in focus.

This is the event that is fired whenever the browser comes into or goes out of focus.

document.addEventListener('visibilitychange', function(e) { console.log(document.hidden); });

The following code is a modification of what you’ll find at the Mozilla Developer Network documentation for the Page Visibility API.

// Set the name of the hidden property and the change event for visibility var hidden, visibilityChange; if (typeof document.hidden !== "undefined") { // Opera 12.10 and Firefox 18 and later support hidden = "hidden"; visibilityChange = "visibilitychange"; state = "visibilityState"; } else if (typeof document.mozHidden !== "undefined") { hidden = "mozHidden"; visibilityChange = "mozvisibilitychange"; state = "mozVisibilityState"; } else if (typeof document.msHidden !== "undefined") { hidden = "msHidden"; visibilityChange = "msvisibilitychange"; state = "msVisibilityState"; } else if (typeof document.webkitHidden !== "undefined") { hidden = "webkitHidden"; visibilityChange = "webkitvisibilitychange"; state = "webkitVisibilityState"; }

We need to determine the correct attribute names based on the browser. So utilizing the code above we will access our hidden property like this:

document[hidden]

document.hidden

document.addEventListener(visibilityChange, function() { console.log(document[hidden]); });

With the code above, you can switch tabs and it will log the state to the console.

Check out our page-visibility module on Github. We will probably expand this over time, but the main purpose is to abstract the code that makes this thing cross browser compatible. So with our module, instead of doing this:

document[hidden]

or

document.hidden

you can do:

Visibility.isHidden()

And you can also get the event name easily:

document.addEventListener(Visibility.visibilitychange, function() { console.log(Visibility.isHidden()); });

And if you want your callback to run only the first time the page becomes visible you can do this:

document.addEventListener(Visibility.visibilitychange, function(e) { var hidden = Visibility.isHidden(); if (!hidden) { console.log('This first only the first time the page is visible!!'); e.target.removeEventListener(e.type, arguments.callee); } });

In the top right of your browser, you’ll find the profile icon. Click on it, and a dropdown will appear. Then click Manage People.

In my case, I’m deleting a profile called “Person 1”. If you hover over the profile square, the details icon will appear. Click it.

A dropdown will appear with a few options, click Remove This Person. You’ll be given an opportunity to confirm your intentions, and you’ll need to click Remove This Person once more.

At this point, you’ve delete the Google Chrome profile!

From the docs, here’s the basic usage:

kubectl cp  

The kubectl cp command takes two parameters. The first is the source; the second is the destination. As with scp, either parameter (source or destination files) can refer to a local or remote file.

Before we begin

We need to make sure our kubernetes client is authenticated with a cluster. There are many ways to authenticate, but authentication is outside the scope of this guide.

Second, we’ll need to identify the name of a pod (or pods) that we want to work with. We’ll need to use kubectl get pod to find the name of the pod(s), and we’ll use these names in the following sections.

Copy file from local machine to pod

Suppose we want to move a file from our local machine to a pod.

kubectl cp /path/to/file my-pod:/path/to/file

In the above example, we copied a local file /path/to/file to a pod named, my-pod. We’ve specified an identical path on the pod to copy the file. Notice that we used an absolute path in both cases. We can also use relative paths:

kubectl cp my-file my-pod:my-file

In this example, we’ve specified a relative path to a local file, and a relative path on the pod. One key difference between kubectl cp and a tool like scp is that with kubernetes, the file is copied relative to the working directory, not the home directory.

Copy file from a pod to a pod

Similarly, we can copy a file from one pod to another. The same rules for absolute and relative paths apply.

kubectl cp pod-1:my-file pod-2:my-file

Copy file from pod to your local machine

As you might have guessed, you simply swap the parameters from the first example.

kubectl cp my-pod:my-file my-file

This will copy my-file from the working directory of your pod to your current directory.

Copying directories

When using scp to copy directories, we’re accustomed to adding the -r (recursive) flag. With kubectl cp this is implied. You use the exact same syntax to copy directories is you would files.

kubectl cp my-dir my-pod:my-dir

Specifying a container

In some cases, you may be running multiple containers on a pod. In which case, you’ll need to specify the container. You can do so with -c, which is consistent with most other kubectl commands.

kubectl cp my-file my-pod:my-file -c my-container-name

Using an ethernet cable or WiFi, connect your Raspberry Pi to your local network. Make sure the device is powered on.

Open a shell on Unix systems, or open the Command Prompt on Windows and run the following command:

ping raspi

This should ping your Raspberry Pi and return its IP address. If you see an error similar to cannot resolve raspi: Unknown host, try running the following instead:

ping raspberrypi

If you’re running RetroPie, you can try the following hostname:

ping retropie

If you’re having problems with this, or if you have multiple Raspberry Pi’s on the same network move on to the next step.

We can use nmap to scan our local network to find all devices that are connected. To do this we’ll have to find the IP address of our local computer.

macOS

On a Mac, open the Network Utility (cmd + space, then search for Network Utility).

Windows

On Windows, open the Network and Sharing Center (Control Panel > Network and Sharing Center > View network connections).

Linux

And on linux, type hostname -I in a shell.

You’re IP address will likely be something like: 192.168.1.181. So other devices on the same network are going to have addresses that share the first three octets: 192.168.1. The notation to describe the entire range of IP addresses between 192.168.1.0 and 192.168.1.255 is 192.168.1.0/24.

Once we determine the subnet range, we’ll use it with the nmap command:

nmap -sn 192.168.1.0/24

If you’re running on a unix system, you might be required to run this command using sudo:

sudo nmap -sn 192.168.1.0/24

You’ll then see a list of devices connected to the network:

Nmap scan report for Chromecast.attlocal.net (192.168.1.78)
Host is up (0.042s latency).
MAC Address: 54:60:09:06:76:0A (Google)
Nmap scan report for unknownc24b2b235d18.attlocal.net (192.168.1.178)
Host is up (0.038s latency).
MAC Address: C2:4B:2B:23:5D:18 (Unknown)
Nmap scan report for docker1.attlocal.net (192.168.1.181)
Host is up (0.51s latency).
MAC Address: B8:27:EB:79:49:F2 (Raspberry Pi Foundation)
Nmap scan report for raspberrypi.attlocal.net (192.168.1.183)
Host is up (0.51s latency).
MAC Address: B8:27:EB:95:6D:7A (Raspberry Pi Foundation)

You’ll notice here that I have a few devices, but after a quick scan you’ll notice a few Raspberry Pi’s connected to the network. From here you can discover the IP address for each Pi.

Before we get going, we need to get set up. So first, make sure you have access to a shell. On many unix platforms, you can use an app called Terminal, on Windows you can use PowerShell.

This may go without saying, but we must have a user configured (with SSH access) on a remote server. If you have a login user, make sure you know the username and password. For the remainder of this guide we’ll use the following variables $USER and $PASSWORD to identify the credentials on the remote server. You can set these variables in your shell session to make copying and pasting these commands easier.

Obviously, replace the values with your own.

Linux + macOS

USER=remoteuser PASSWORD=remotepassword REMOTE=192.168.1.34

Windows

Before you can ssh into a server with PowerShell, you need to install OpenSSH. Open PowerShell as an administrator, and run the following command.

Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0 

To remote into a server using ssh with PowerShell, run the following command with your username and server address. You don’t need an administrator instance of PowerShell to complete this step.

ssh $USER@$REMOTE 

You will be prompted for a password.

To get started, we’ll need to generate SSH keys. I’ll cover the basic instructions in this step, but you can follow the linked guide for more details.

Linux + macOS

Open a shell, and type the following:

ssh-keygen -t rsa

You’ll be asked for a location and passphrase. Unless you need to do otherwise, just use the default location and skip the passphrase. Hit enter when both prompts appear to continue.

Windows

Open PowerShell and run the following:

ssh-keygen 

The keys will be generated in the specified directory, usually C:UsersYour_Username/.ssh. You will be prompted to create a passphrase, but it isn’t required.

To add the keys to the local Windows 10 keystore, run the following:

Start-Service ssh-agent ssh-add ..sshid_rsa 

Now we’ll copy the public key to the remote server:

Linux + macOS

scp ~/.ssh/id_rsa.pub $USER@$REMOTE:

Windows

PowerShell doesn’t have a file transfer protocol built into it. You will need to move the public key to the remote server using a third-party application like PuTTY or WinSCP.

ssh $USER@$REMOTE

This should be the last time you have to enter your password.

Now we’ll need to move the contents of our public key to a new location, and delete the original key file.

cat id_rsa.pub >> .ssh/authorized_keys rm id_rsa.pub

You might need to create the .ssh directory. If so, run the following before the commands above:

mkdir .ssh

It’s essential that .ssh and authorized_keys have the correct set of permissions, otherwise login will fail. The .ssh directory should be 700 (meaning the user has full permissions, while group and global users do not). The authorized_keys file should be 600 (meaning the user can read and write, but group and global users have no access).

chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys

Now, our work is done, and we can log out.

logout

Next time you SSH in to this remote machine, you should not be prompted for a password!

ssh $USER@$REMOTE