Fork me on GitHub
#off-topic
<
2020-10-22
>
jumar04:10:03

If you do remote pair/mob programming what format and tools/platform(s) do you use? We want to improve knowledge sharing in our team and decided to try regular "mob programming" sessions - e.g. UI-focused devs introducing our ui library and concepts behind it and then trying to implement a small, but real, feature together. Our devs use a variety of tools - Emacs, IntelliJ, VSCode, ... I did some pair programming in the past but never remotely and I'm afraid it's gonna be very challenging to make it a good experience.

Stefan06:10:37

@jumar Like @pez said I’ve indeed been doing remote pair programming a lot. It hugely helps when you know each other already a bit by the way, but I’m also doing it in my new job that I started Sept 1 with a colleague who I met about 5 times in the office, and it’s working great. In terms of tooling: I have used Teams screen sharing in the past, which also offers both participants their own mouse cursor and both can type at the same time. VSCode Live Share is a lot nicer though; using that each has their own setup of vscode (including colors, key bindings, layout, plugins, etc) but you’re still working on the same code base. Because we also need to test stuff in the browser for example, we also combine it with screen sharing, but that’s view-only because we have VSCode. This combo works very well for us. Some things that I have to remind myself at least daily: • Take breaks; it way too easy to forget that when doing remote pair programming (don’t ask my why); • Make sure you spend some time on non-work talk as well with your colleague. Just chit chat about things that you might also talk about at the coffee machine at work. I want to try something like live share today with IntellIJ by the way. It appears that there are third-party plugins for that. Does anybody have experience with any of those?

jumar08:10:42

Nice, thanks a lot for all the details! Btw intellij recently released a special “plugin” for that I think

Stefan08:10:51

That would be interesting, thanks!

Stefan14:10:44

I found the Jetbrains thing you mentioned, @jumar: https://blog.jetbrains.com/blog/2020/09/28/code-with-me-eap/. Trying that now. Still quite limited and rough around the edges I guess.

jumar14:10:22

Yes, that's it - haven't tried it yet but want to do so because we have a first session next friday

jumar14:10:12

One question regarding this VSCode/Intellij-style interactions. What about the running app itself? Like sharing a running REPL session? Is that possible?

pez16:10:20

Not sure if I understand the question, but I think the answer is yes. @stefan.van.den.oord wrote these docs, when he fixed Live Share support in Calva: https://calva.io/live-share/

Stefan16:10:00

@pez We should make that screencast soon 🙂

pez16:10:07

There is a Youtube channel that needs some content. 😃 https://www.youtube.com/channel/UCakZ_CPx4T2QXGEgyFEFGqQ

jumar06:10:00

Yes, I think that's what I'm after - sharing the REPL between participants.

noisesmith05:10:53

tmate works if you can accept the security implications and all parties are comfortable with the tmux UI https://tmate.io/

noisesmith05:10:20

it doesn't work for a non tty frontend though

dpsutton05:10:25

at my last job we would use zoom screen sharing and git mob to sign multiple authors onto commits. its not great for mid work handoffs but is good for pairing if its more driver/passenger style

pez07:10:29

I know @stefan.van.den.oord is using a combination of video sharing and VS Code Live Share. Where I work I’m the only one using VS Code so it’s Zoom only for when pair programming. Which works pretty nicely, but, as @dpsutton says, a bit more of spectator sport. Switch drivers often somewhat compensates.

bherrmann12:10:23

@jumar I've been using http://screen.so for pairing - and it is mostly great. Both users get a cursor and can type and/or mark up a shared screen.

jumar13:10:07

Thanks, that looks interesting! I'll check it in more details but it looks similar to what @stefan.van.den.oord described in https://clojurians.slack.com/archives/C03RZGPG3/p1603435297465000?thread_ts=1603342023.432700&amp;cid=C03RZGPG3 > I have used Teams screen sharing in the past, which also offers both participants their own mouse cursor and both can type at the same time. VSCode Live Share is a lot nicer though; using that each has their own setup of vscode (including colors, key bindings, layout, plugins, etc) but you’re still working on the same code base. @U0502D2GL do you basically only work on a single machine where the app is running and all the changes stay there? Or do you switch turns in which case you have to push changes and pull them and potentially rebuild/restart the app(s) on the other end ?

bherrmann13:10:57

@jumar Yes, single machine.

Frank Henard17:10:44

My company is moving away from Clojure and I'm very sad. I was discussing with another developer, and he mentioned Clojure wasn't on the 2020 stackoverflow survey, but it did pretty well in the 2019. Does anyone have any insight into that?

😥 6
Alex Miller (Clojure team)17:10:42

they removed it, not sure why

Alex Miller (Clojure team)18:10:27

for various reasons (like this Slack), Clojure is not particularly active on SO, so presumably that's a reason

Frank Henard18:10:11

I see, thanks Alex!

dhd23:10:54

really off topic here but looking for ideas. Problem: I am writing a client which will run specific tests on the users computer (they clone the code and run it in docker). Once the user runs the test, the client needs to publish the results to the server (this happens in the background without the user being concerned about it. but the user know this is happening). The user needs to be authenticated to publish anything to the server. Also, the users I am dealing with do not want to be prompted to enter their credentials, they are just concerned with running their tests. I am told storing their own credentials in a file on their computer is also a no go. A solution: 1. Ask the users to authenticate once with the server and get back an access token. 2. Store the access token on the file system (at some specific location) 3. (Steps 1 and 2 will happen only the first time or if the user looses the token) 4. The token will be stored in a DB so even if the app restarts, it will be saved without the hassle of re-creating it. 5. The user will run the tests and once the tests are finished, the client will use the token to authenticate with the server and publish their results. This solution seems a bit fragile. I have searched the web and I see things like API keys and auth tokens (i think what I am doing here is using auth token as an API key). Do you guys have an idea how I should approach this. A pointer in the right direction will be very helpful. Thanks.

phronmophobic23:10:07

your solution seems reasonable. seems very similar to how google handles auth with their apis: https://developers.google.com/gmail/api/quickstart/python

phronmophobic23:10:20

when the local credentials don't exist or aren't valid/expired, it goes through an oauth flow with something like: • print a link to open in a browser • the user logs in using their browser • an oauth token is presented to the user • the user copy and pastes the oauth token into the command line

dhd03:10:40

Thank you very much!!

Stefan06:10:37

@jumar Like @pez said I’ve indeed been doing remote pair programming a lot. It hugely helps when you know each other already a bit by the way, but I’m also doing it in my new job that I started Sept 1 with a colleague who I met about 5 times in the office, and it’s working great. In terms of tooling: I have used Teams screen sharing in the past, which also offers both participants their own mouse cursor and both can type at the same time. VSCode Live Share is a lot nicer though; using that each has their own setup of vscode (including colors, key bindings, layout, plugins, etc) but you’re still working on the same code base. Because we also need to test stuff in the browser for example, we also combine it with screen sharing, but that’s view-only because we have VSCode. This combo works very well for us. Some things that I have to remind myself at least daily: • Take breaks; it way too easy to forget that when doing remote pair programming (don’t ask my why); • Make sure you spend some time on non-work talk as well with your colleague. Just chit chat about things that you might also talk about at the coffee machine at work. I want to try something like live share today with IntellIJ by the way. It appears that there are third-party plugins for that. Does anybody have experience with any of those?