My brain is quite stubborn about categorizing spaces my computer room at home is where I do some side project programming and a fair amount of gaming. Interestingly though I fall on the other side of the remote work issue - I cannot wait to return to the office. To me, working on my laptop is doable, but feels like having one hand tied behind my back when compared to working with multiple monitors and a proper keyboard and mouse. Both are long enough that I'll do something else while waiting and suddenly 2 hours pass before I remember, so I like keeping the build status page visible somewhere to avoid that.Įven for non-work/coding sometimes I just have YouTube or Netflix open (either 1/4 window or full-screen) while I'm browsing the web on another. There's a couple things I work on that have long running builds (10+ minutes) or integration tests that takes a bit over 30 mins. Usually chat, documentation, source, issue tracker is mixed in there too. In some cases, I'm debugging remotely, and a monitor will be partly or completely dedicated to ssh/rdp/vnc to the remote system(s), with the other used for browser or cli app I'm testing. The key useful thing is seeing the client do an action and send something to the server, and seeing the server instantly react: that's not possible when you can't see everything. I do lots of client/server stuff, so sometimes I have a monitor showing the server-side (web UI and/or logs) and the other showing client-side (cli, logs, and/or local UI). Or I'll be tailing a log file or watching something in a database while using the app.
#Anydesk android waiting for image code#
When I'm testing/debugging, one monitor might be the web app I'm working on, the other is the code I'm stepping through. Usually that monitor is split and also has chat visible. When I'm coding, I generally have code on one, and the other has a browser with documentation, notes, issue tracker, or just used for searches etc.
Whereas if you use ssh you can be fairly certain that it's been battle tested by a huge number of people who have a lot more time and resources than yourself. I actually think this is better because for a very small open source project like barrier, that might literally be developed by one person, the workload and time/effort to be ABSOLUTELY CERTAIN you've implemented the crypto libraries correctly is a lot of work and worry. In which the VNC daemon on the remote machine only listens on its own localhost, and I use ssh to form the tunnel then use the vnc client on my workstation to connect to localhost:5902 to access it. An example of the very tiny shell script that I use for VNC-over-SSH to a remote machine. I've only used it between macos and linux machines, so that's easy. If I had to guess, no, barrier is much like VNC in that it's expected you have a ssh wrapper set up with public/private key authentication.
0 kommentar(er)
