Clojurians Log v2

How do you edit remote files/directories/projects with Atom and Chlorine?

@ahmed1hsn I don't think Chlorine can help much here (unless you want to connect to a remote REPL 😄). There's probably some package that'll allow Atom to edit remote projects, or files, but I don't use any of then so I'm not confortable recommending it 🙂

Thanks. So, to connect with remote REPL we use port forwarding. Right?

Well, you don't need to: if you open a REPL in a server, and that port is already open to the internet, you can just connect a socket REPL over there, passing a different host than localhost for example. I don't recomend it BTW, it's a serious security flaw, but its possible 😄

So port forwarding seems safer.

We use port forwarding at work (via an ssh tunnel) for this exact case -- for debugging processes on QA and sometimes production. Note that the load-file command (in Chlorine) would execute in the remote context so it's going to assume the file is present at the same filesystem location on the remote server that is in on your local machine!

Consequently, since we do not deploy source to QA/production, we use evaluate top block to send updated function definitions to the remote REPL, or evaluate block (usually from a form inside a comment locally) to just run (local) code against that (remote) REPL.

Note that updating function definitions in a remote REPL means that the running image gets out of sync with the code on disk (JAR files, in our case) so the changes do not survive a restart of the remote process!

Happy to answer more questions about remote REPL connections @ahmed1hsn

> since we do not deploy source to QA/production do you mean you deploy JAR files, instead of running clojure.main? > running image gets out of sync with the code on disk How do you update function definition in JAR file then?

Yes, we deploy (uber) JAR files to QA/production. No source. We used to use clojure.main and deploy source code but we decided to switch so that a) our deployment pipeline is simpler/more standard (build a JAR, in CI effectively, and just push it out to other servers, which can then perform automated rolling restarts of apps that are based on that JAR) and b) we eventually decided to AOT code as part of building the (uber) JAR so that we get faster startup (and therefore our rolling deployments take less "down" time on each server).

If we patch QA/production for any reason and need that to apply over a restart, we'll just kick off a new build/deploy cycle. We can go from a local change to full production rollout in just a few minutes, if we really need to, so there's rarely much time between a hot fix and an actual release.