There are 3 steps involved:
Connect to the remote machine, get the pid of the Node.js process and then run:
kill -usr1 <pid>
// @include https://raw.githubusercontent.com/luciopaiva/foo/master/bar.js |
#!/usr/bin/env node | |
const | |
path = require("path"), | |
fs = require("fs"); | |
/** | |
* List all files in a directory recursively in a synchronous fashion | |
* | |
* @param {String} dir |
Using apps to fake GPS location, like Fake GPS, is not enough to trick some apps into thinking they are somewhere else.
One obvious thing to do is to use a VPN to spoof your ISP location as well, but there's more.
Apps also rely on the "Improve location accurary" that you can find on your Android settings. When that is turned on, geolocation also uses info about nearby wifi and cellular signals. If you turn that option off, the app will tell you it needs location info to work and will refuse to continue. As far as I know, there's no way to circumvent that without rooting the phone or running the app on an emulator.
One easy option, though, is that sometimes apps have equivalent versions running as web apps, and web apps cannot fetch location info as easily. If the app you're trying to use has a web version, just turn the VPN on and you should be able to use it just fine.
If you need to cast to Chromecast, it will probably not work unless you configure the VPN directly into your home router.
This is a simple example of how to get a concurrency issue in JavaScript while using async/await.
In the initial example, async-concurreny-issue.js
, the main function starts two tasks that were supposed to run asynchronously. The big problem here is that runTask()
has side effects and changes an internal state represented by currentTaskId
. After going through a function call that requires awaiting on a promise (promiseMe()
), the task expects currentTaskId
to still have the same id assigned to it a couple of lines above. Even if promiseMe()
does actually nothing, it will still execute asynchronously. That should be no problem because we are await
ing on it in runTask()
, right? Yeah, but the problem is that main()
is not doing its job and await
is not being used there. This means that main()
fires runTask(2)
immediately after calling runTask(1)
, so it runs before the call to promiseMe()
has the chance to return - it can only return in the next event loop tick, since it is behind a p
:root { | |
--app-width: 1000px; | |
--some-calculation: calc(var(--app-width) + 1); | |
} |
General pattern:
ssh bridge-machine -L local-port:destination-machine:destination-port -N
Where bridge-machine
is the machine providing an ssh server that will act as a bridge to the destionation-machine
. The destionation machine could be, for instance, a database, a Redis server, etc, that is not accessible from your network, but is accessible via another server (the bridge) that you are able to access via SSH.
I always forget which port is the local one is which is the remote. One nice mnemonic is to remember that Left is Local, Right is Remote.
General steps: | |
- download Microsoft Remote Desktop app on client machine (check the Apple store) | |
- enable remote access on host Windows (window key, type "allow remote access" to find the setting) | |
- test the connection using the Remote Desktop app. Notice that any current logged in users on the host machine will need to log out | |
- download [RDP Wrapper](https://github.com/stascorp/rdpwrap/releases) - I tested with v1.6.2. The msi installer did not work for me (got an error trying to execute it), but the zip worked fine | |
- unzip, run install.bat | |
- run the "*conf*.exe" app that comes with the zip | |
- it should show all green - if it shows a red "[not supported]", continue below | |
- get the ini file posted by Damasker [here](https://github.com/stascorp/rdpwrap/issues/1252). As instructed, run `net stop TermService`, replace the ini file in `Program Files/RDP Wrapper`, then `net start TermService` |
The aseprite docs help with building it from the command line. Here I show how to build it via CLion. It is surprinsingly simple!
First, follow the instrucions in INSTALLATION.md. I will summarize here what I had to follow when building tag v1.3-beta11
:
main
branch or switch to the desired tag. For example, this is how I switched to v1.3-beta11
:git checkout tags/v1.3-beta11 -b v1.3-beta11
/* | |
* This script changes the timestamps of a series of files in batch. The script will go through all files in | |
* specified folder, ordering them by name. The first file will be stamped with given start date. The second one will | |
* be stamped with start date plus 1 second, the third with start date plus 2 seconds, and so on. | |
* | |
* But why? I had a series of photos that I wanted to upload to the cloud and their timestamps did not represent the | |
* actual date when they were taken. The photos were all taken in the same day and I knew what day was that, so I just | |
* needed a script to do it in batch for me. Also, files were sequentially named by the digital camera, and although I | |
* didn't know the exact time of day each photo was taken, I could at least preserve the sequence, that's why I decided | |
* to stamp each one second after the other, ordered by name. |